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Preface 


The  AFIT/ENG  database  has  the  ability  to  store  and 
manipulate  student  and  faculty  data  utilizing  the  TOTAL  Database 
Management  System  and  the  Forms  Management  System.  This  study 
was  undertaken  to  design  the  complex  network  of  application 
programs  needed  to  maintain  the  database  system.  Additionally,  a 
library  of  standard  routines  were  created  to  ease  the  amount  of 
code  needed  to  create  the  programs  and  aid  in  the  maintenance  of 
the  system.  One  of  the  programs  was  implemented  and  tested  to 
validate  the  design  and  to  serve  as  an  example  of  how  the 
standard  routines  were  implemented. 

I  would  like  to  thank  my  advisor,  Dr  Gary  B.  Lamont  for  his 
time,  expertise,  and  confidence  in  my  abilities.  Additionally,  I 
would  like  to  thank  Robert  Ewing  and  Captain  Steve  Woffinden  for 
their  assistance  in  guiding  me  through  the  experience  of  writing 
a  thesis.  Finally,  I  would  like  to  express  my  sincere  gratitude 
to  my  wife,  Cindy,  for  her  never  ending  faith  and  encouragement 
through  this  assignment  and  the  past  nine  years. 
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Abstract 

This  study  took  the  works  of  the  previous  AFIT/ENG  Student 
and  Faculty  Database  system  thesis  efforts  and  design  and 
implemented  the  application  software  for  the  project.  The  basic 
purpose  of  the  thesis  was  to  provide  a  sound  design  for  the 
application  programs  that  would  interface  with  the  TOTAL  Database 
Management  System  and  the  Forms  Management  System.  The  entire 
system  was  to  be  designed  with  the  notion  that  it  would  be 
modified  and  enhanced.  A  series  of  standard  interface  routines 
were  created  to  act  as  a  layer  between  the  TOTAL  DBMS.  The 
resulting  routines  were  abstracted  and  used  as  an  extension  to 
the  Pascal  programming  language. 

The  education  plan  portion  of  the  database  was  used  as  a 
prototype  to  develop  the  requirements  of  the  human-computer 
interface.  The  program  was  then  redesigned  and  implemented  using 
the  standard  routines  and  the  specifications  developed  from  the 
prototype.  A  menu  driven  system  was  used  to  implement  the  design 
utilizing  the  Forms  Management  System  as  the  screen  interface. 

The  education  plan  program  is  an  example  of  the  structured 
approach  used  in  interpreting  the  design  of  the  database  system. 
The  program  contains  examples  of  scrolled  screens,  database 
calls,  linked  list  routines,  and  data  abstraction.  Additional 
programs  were  written  to  demonstrate  the  capabilities  interfacing 
with  the  GKS  graphics  package,  transmition  of  data  to  the 
registrars  office,  and  to  show  the  continuity  of  the  design. 


Chapter  1 


I.  Introduction 


Background 

A  database  management  system  is  a  computer  based  system 
whose  overall  purpose  is  to  record  and  retrieve  information. 
(1:3).  Database  management  systems  offer  a  convenient  and 
practical  means  to  store,  manipulate,  and  retrieve  information. 
There  are  three  basic  types  of  database  systems:  relational, 
hierarchial,  and  ne twor k { 1 :  4 50)  •  The  relational  database 
represents  the  information  as  a  series  of  tables.  The 
hierarchial  database  represents  information  as  a  tree  structure 
with  some  data  being  subordinate  to  other  data  or  records.  The 
network  database  is  by  far  the  most  complex  because  it  involves 
linking  related  pieces  of  information  together  to  avoid 
duplication.  This  structure  provides  the  user  of  the  database  a 
great  deal  of  flexibility  in  storing  and  retreiving  large  amounts 


of  data. 


The  Air  Force  Institute  of  Technololgy  (AFIT) 


School  Engineering,  Department  of  Electrical  and  Computer 
Engineering  has  a  need  to  maintain  information  on  students, 
faculty,  courses,  and  class  rooms.  Several  proposals  for  an 
AFIT/ENG  database  have  been  submitted  and  a  prototype  is  under 
construction  in  the  Department  of  Electrical  and  Computer 
Engineering,  Information  Sciences  Laboratory.  This  project  is 
under  the  supervision  of  Dr.  Gary  B.  Lamont  and  Engineer  Robert 
Ewing  and  is  designed  to  provide  students  with  a  valuable 
learning  tool  and  a  service  to  the  School  of  Engineering.  The 


overall  purpose  of  this  thesis  project  is  to  establish  a  working 
database  manangement  system  for  the  Department  of  Electrical  and 
Computer  Engineering,  AFIT. 

Three  AFIT/EN  thesis  written  by  Jeffrey  S.  Ricks,  Robert  S. 
Colburn,  Dean  S.  Alfred,  and  Myron  E.  Pangman  have  proposed  a 
database  management  system  in  detail  using  the  VAX  11/780  (VMS 
Operating  System)  and  a  network  database  system  called  TOTAL. 
These  theses  describe  in  detail  the  file  types,  display  forms, 
network  schemes,  dataset  selections,  data  description  language, 
and  anticipated  application  program  design  as  well  as  the 
feasibility  of  such  a  project.  The  design  of  the  database  was 
approached  as  a  solution  to  the  demands  of  the  Electrical  and 
Computer  Engineering  Department's  request  to  store  and  manipulate 
more  information.  The  design  was  intended  to  create  a  "user- 
friendly"  information  center  using  the  database  system  T0TAL(16), 
a  forms  management  utility  called  FMS(10),  and  an  application 
programming  language  such  as  FORTRAN  or  PASCAL. 

This  proposed  database  management  system  is  being  used  in 
classroom  projects  in  EE  6.46  (Computer  Database  Systems),  and 
DBTA  efforts.  This  has  given  students  the  opportunity  to  work  on 
a  real  database  system,  write  applications  programs,  and  use 
schemas  while  studying  DBMS  concepts.  During  these  courses 
several  modifications  and  enhancements  were  suggested  to  improve 
the  efficiency  and  make  the  system  more  "user-friendly". 
Statement  of  Problem 

The  purpose  of  this  thesis  investigation  is  to  analyze 
previous  thesis  effort  design  and  implementation,  the  work  done 
by  the  students  of  previous  EE  6.46  classes,  and  indentify 
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modifications  and  enhancements.  The  modifications  to  the  schemas 


and  application  software  will  be  reviewed  and  incorporate  in  the 
system.  A  formal  design  phase  will  be  conducted  to  reflect 
modifications  to  the  new  schema  and  enhancements.  The 
application  programs  developed  as  class  projects  will  be  reviewed 
for  further  ideas  to  aid  in  the  design  of  a  complete  software 
package  to  implement  the  database  structure.  A  study  will  be 
conducted  to  test  the  feasibility  of  linking  the  AFIT/EN  Database 
Management  System  with  the  AFIT  scheduling  system  and  integrating 
a  backup  and  restore  capability  into  the  design.  The  system  will 
be  designed  to  generate  the  Division  Facutly  Schedule  and 
Manpower  Requirement  and  Expenditure  document  as  prepared  by  the 
School  of  Engineering.  This  feature  will  take  the  instructors 
hours  spent  on  teaching  classes,  conducting  short  courses,  thesis 
students,  and  PHD  students  and  generate  statistics  based  on  this 
data.  Requirements  for  generating  a  graphical  representation  of 
the  data  for  managment  information  needs  will  be  conducted.  The 
overal  design  will  include  the  use  of  a  commercial  form  display 
technique  called  FMS  that  is  currently  available  on  the  ISL  VAX 
11/780  (VMS  Operating  System). 


The  purpose  of  this  thesis  effort  is  to  identify  existing 
problems  with  the  database  system  and  concentrate  on  the  design 
of  the  system.  The  study  will  confine  the  use  of  the  database 
system  to  the  AFIT/ENG  Department  although  recognizing  the  need 
for  an  all-inclusive  AFIT  database  (2:1-3)  This  effort  will 
provide  a  solid  base  for  further  program  development  and 
implementation  by  enhancing  the  current  database  schema, 
analyzing  current  user  needs,  and  providing  a  detailed  design 
analysis  of  the  overall  database  system.  Software  design  for 
this  project  will  consider  time  and  space  requirements  into 
consideration  for  algorithm  design.  In  addition,  a  portion  of  the 
design  will  be  implemented  for  use  by  the  faculty  and  students. 
Assumptions 

No  attempt  will  be  made  to  justify  the  need  for  an  AFIT/EN 
database  system  nor  will  any  attempt  be  made  to  analyze  the  need 
to  apply  another  type  of  database  such  as  a  relational  or 
hierarchial.  It's  assumed  that  these  topics  were  discussed  in 
sufficient  detail  in  previous  thesis  efforts  (2). 

Summary  of  Current  Knowledge 

The  proposed  AFIT  Database  (2)  currently  contains 
information  and  schema  definitions  on  faculty,  departments, 
students,  thesis,  section  leaders,  school  courses,  school 
quarters,  course  text  books,  class  times,  room  capacities, 
schedules,  master  degree  requirements,  and  course  sequences. 


(See  Appendix  A)  Several  enhancements  to  the  schema  have  been 
proposed  by  students  in  the  EE  6.46  class  while  developing 
application  programs  for  the  AFIT  Database  System.  Some  of 


these  enhancements  are  a  direct  result  of  the  changing 
requirements  for  a  database  system  and  others  stem  from  the 
introduction  of  new  or  improved  software  and  hardware 
capabilities  in  the  Information  Sciences  Laboratory. 
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Standards  and  Notations 


The  time  analysis  for  algorithms  will  use  the  notation  0(n) 
which  transalates  to  big-oh  of  n  (3:21-23).  This  indicates  that 
the  algorithm  takes  an  order  of  time  to  execute  which  is 
dependent  upon  the  number  of  inputs  designated  by  "n".  Space 
analysis  of  an  algorithm  will  also  be  in  terms  of  the  number  of 
inputs  designated  by  "n". 

Structure  charts  developed  by  Stevens,  Myers,  and  Constatine 
(4:60)  will  be  used  to  represent  the  modular  characteristics  of 
the  applications  programs.  These  charts  will  be  used  because  of 
the  highly  modular  and  structured  design  of  the  proposed  system. 
The  Software  Development  Workbench  (SDW)  will  be  used  as  the 
automated  tool  for  designing  and  documenting  the  development  of 
the  system.  Sructure  charts  and  diagrams  will  be  drawn  on  the 
system  flowchart  portion  of  the  graphics  editor  while  the  SADT 
charts  will  be  drawn  on  the  AUTOIDEF  (8:173)  of  the  Requirements 
Definitions  portion  of  the  Software  Development  Workbench  (SDW). 
The  use  of  the  SDW  is  intended  to  decrease  the  number  of  errors 
in  the  software  and  to  allow  easy  changes  to  the  preliminary 
design  of  the  sytem.  Documentation  standards  will  conform  to  the 
AFIT/ENG  Development  Documentation  Guidelines  Draft  #2  and 
Standards  document  published  September  26,  1984. 

Approach 

The  project  will  consist  of  the  following  phases. 

1)  A  preliminary  evaluation  of  the  current  AFI7/EN  Database 
will  be  conducted  to  identify  deficiencies  and  weaknesses  in  the 
schema.  Reevaluation  of  the  current  requirements  will  be 
necessary  because  of  the  time  from  the  last  research  done  on  this 


topic  (1983) . 


2)  Interviews  and  research  will  be  conducted  to  find  any 
additional  errors  that  have  been  found  by  previous  EE  6.46 
classes  in  their  efforts  to  write  software  to  interface  with  the 
database.  Enhancements  to  the  database  schema  will  be  included 
with  this  phase  to  accomodate  new  requirements  for  information. 

3)  A  new  database  schema  will  be  completed  and  compiled  to 
reflect  the  changes  made  as  a  result  of  the  investigation. 

4)  Input  and  output  standards  to  the  new  database  will  be 
completed  to  establish  guidelines  for  future  efforts.  An  updated 
version  of  the  Frames  Management  System  (FMS  Version  2.1)  will  be 
used  as  the  input/output  media.  The  objective  will  be  to  make  a 
self  documenting  system,  easing  the  burden  on  the  user  by  using  a 
menu  driven  system  with  query  capability.  An  alternative  system 
could  use  the  lower  level  modules  to  develop  a  command  driven 
system  for  the  expert  users  and  on  remote  terminals  with  limited 
graphic  capability. 

5)  An  initial  design  of  the  system  will  follow  the  top-down 
structured  design  techniques  with  emphasis  placed  on  efficiency 
of  the  program  modules.  At  the  same  time,  a  bottom  up 
development  will  be  conducted  to  design  the  abstract  routines 
needed  to  interface  with  the  TOTAL  DBMS.  This  will  be  done  to 
provide  an  abstraction  between  the  programmer  and  the  database 
system  and  to  facilitate  the  coding  phase  of  the  development 
cycle . 

6)  A  study  will  be  conducted  to  address  the  feasibility  of 
using  a  graphics  package  to  generate  graphs  of  managment 
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information  compiled  by  the  DBMS.  Examples  of  this  would  include 
the  representaion  of  the  Division  Faculty  Schedule  and  Manpower 
Requirement  Expenditure  Document  as  a  bar  chart  of  faculty  and 
division  manpower  utilization. 

7)  A  portion  of  the  design  will  be  implemented  to  further 
establish  programming  and  documentation  standards  and  to 
demonstrate  the  usefulness  of  the  database  system  to  the  faculty. 
The  majority  of  the  development  will  be  in  the  main  module 
programs  and  the  bottom  layer  utility  programs. 

Mater ials  and  Equipment 

Implementation  and  testing  will  be  done  on  the  ISL  VAX 
11/780  computer  system  with  the  VMS  operating  system,  and 
application  programs.  Enough  disk  memory  space  will  be  required 
to  hold  a  test  database  and  associated  utililty  software.  A 
nine-track  tape  drive  system  will  be  required  to  backup  software, 
data,  and  documentation  in  case  of  system  failure.  A  work 
station  for  this  project  is  required  and  will  include  a  desk  and 
a  computer  terminal  with  connection  to  the  VAX  11/780  located  in 
the  Information  Sciences  Laboratory  (ISL). 

Other  Suppor  t 

The  cooperation  of  the  faculty  and  students  in  gathering 
current  data  to  test  the  database  is  required  as  well  as  the 
software  developed  in  past  EE  6.46  efforts  to  aid  in  the  design 
of  the  database  system.  These  efforts  will  aid  in  identifying 
past  deficiencies  and  contribute  to  the  accuracy  of  the  testing 
of  specific  algorithms.  The  Software  Development  Workbench  (SDW) 
will  be  used  as  the  automated  design  tool  to  aid  in  the  design 
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Chapter  2 


I I .  General  Approach  to  Requi remen ts  Definition 

This  chapter  will  cover  the  functional  requirements 
for  a  student  and  faculty  database  system.  This  section  of  the 
thesis  will  deal  directly  with  the  targeted  users  of  the  proposed 
system  in  trying  to  establish  the  requirements  for  the  system. 
Previous  work  done  by  Allred  (12),  Ricks  and  Colburn  (13  ),  and 
Pangman  (2)  were  to  define  the  AFIT/ENG  database  and  to 
implement  the  database  schema.  These  theses  efforts 
focused  on  the  initial  requirements  for  information  to  be 
contained  in  a  database  for  The  AFIT  School  of  Engineering.  In  the 
software  development  life  cycle  (4:13),  the  steps  through  the 
requirements  definition  have  been  reached  on  the  database  schema 
design.  As  discussed  in  chapter  1,  the  design  of  the  application 
software  has  been  largely  ignored.  A  review  of  the  initial 
concepts  and  requirements  of  the  database  schema  will  be 
conducted  to  insure  that  the  current  configuration  supports  these 
requirements.  In  addition,  requirements  for  the  application 
software  will  be  defined  in  this  chapter.  The  software 
requirements  definition  phase  for  this  software  design  will  be 
divided  into  two  parts,  the  functional  requirements  and  the  user 
interface  requirments. 

The  first  part  is  the  functional  requirements  of  the  system 
and  defines  what  the  system  must  be  able  to  provide  to  the  using 
organization  and  design  how  it  will  be  done.  The  topics  to  be 
covered  are  modular  grouping  of  the  software,  standard  database 
functions  (ADD,  UPDATE,  DELETE,  REVIEW),  the  limitations  placed 


on  the  system,  response  time,  memory  requirements,  graphic 
capabilities,  required  reports,  and  data  syntax  and  compatibility 
checks . 

The  second  part  of  the  requirements  definition  phase  is 
defining  the  "human  computer  interface"  of  the  system.  This 
section  will  describe  the  design  of  the  interfaces  to  the  system. 
The  success  of  the  design  effort  depends  a  great  deal  on  how 
effectively  the  methodology  externalizes  issues  with  each  group 
in  the  human  interface  (4:202).  In  this  section  a  targeted  group 
of  users  will  be  defined  so  a  profile  of  the  "average  user"  can 
be  defined.  In  the  requirement  definition  phase,  interaction 
between  the  analyst  and  the  user  is  very  important  to  the  success 
of  any  design.  One  of  the  most  common  reasons  systems  fail  is 
because  the  definition  of  system  requirements  is  inadequate 
(14:139).  Assumptions  on  the  experience  level  of  the  user  are 
necessary  in  developing  the  requirements  for  the  interface  portion 
of  the  software.  A  prototype  database  application  program  of  the 
education  plan  ( EDPLAN)  system  will  be  constructed  to  further 
define  the  requirements  of  the  user.  By  experimenting  with  this 
program  and  gaining  user  feedback  the  interface  and  functional 
requirements  can  be  further  refined.  This  will  also  give  the 
eventual  users  of  the  system  a  hand  in  the  developement  which 
should  make  implementation  easier.  A  complete  requirements  list 
developed  this  and  previous  thesis  efforts  can  be  found  in 
Appendix  F  and  will  be  referenced  thourghout  this  chapter. 

The  users  seem  to  be  more  satisfied  with  a  qualitative 


definition  which,  in  many  cases,  specifies  the  system  in 
generalities  and  in  terms  of  benefits  to  be  derived.  To  reach 


the  level  of  detail  that  the  designer  wants,  the  users  must 
actually  enter  what  they  consider  to  be  problem  solving,  or 
design  (how)  mode:  they  must  arrive  at  functions  that  will  solve 
their  problems.  Designers  of  systems  are  usually  thinking  a  step 
ahead  of  the  user  (14:140).  Table  2-1  (  extracted  form  the 
article  Pinpoint  Requirments  (14:140))  shows  the  analyst  or 
designer  views  as  apposed  to  the  users  views. 
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j  THE  OBJECTIVE  OF  REQUIREMENTS  DEFINITION 

I 
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Functional  definition 
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Favorable  impact  of 

implemented  within 
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schedule  and  budject 

mental  budgets 

Good  system 

System  will  work 

Figure  2-1  Objective  of  Requirements  Definition 


Database  Schema  Review  and  Mod ification 

The  current  database  schema  was  reviewed  during  the 
development  work  in  the  fall  session  of  the  computer  database 
class  EE  6.46.  Several  enhancements  and  modifications  were 
recommended  by  the  classes  during  that  session.  It  was  very 
important  to  establish  the  database  schema  early  in  the 
requirments  phase  in  order  to  provide  a  solid  base  by  which  to 
design  the  application  software.  The  schema  is  important  because 


it  defines  the  relationships  of  data  and  records  to  each  other 
and  also  defines  the  very  essence  of  the  database  system.  The 
modifications  discussed  below  are  a  direct  result  from  an  early 
investigation  into  the  database  schema  (Requirement  1,  Appendix 
F)  .  The  first  real  users  of  the  new  database  were  the  new 
Engineering  and  Computer  Science  students  entering  the  summer 
1985  quarter. 

Several  of  the  network  relationships  within  the  database 
posed  a  problem  with  the  current  configuration.  The  first  problem 
was  found  in  the  Master  Degree  Requirements  Fi le ( Requi remen t  1.1, 
Appendix  F) .  This  file  maintained  the  different  graduate  degree 
programs  and  the  minimum  requirements  needed  for  graduation. 

Within  this  file  was  a  link  to  a  students  social  security  number. 
The  file  could  not  be  created  unless  a  students  social  security 
number  was  assigned  to  that  field.  Previous  thesis  efforts  were 
searched  to  determine  what  purpose  the  field  served.  After 
finding  no  valid  purpose,  the  field  was  deleted  from  the  schema. 

There  exists  within  the  originial  schema  two  files  that  hold 
text  book  information.  The  Master  Text  Book  File  holds 
information  on  required  text  books  for  a  particular  class,  the 
Master  Book  File  holds  information  on  books  associated  with  a 
class  but  on  a  more  detailed  manner.  Since  the  Master  Book  File 
was  also  connected  via  links  to  AFIT  courses,  a  duplication  of 
information  was  indicated.  The  Master  Text  Book  File  was  deleted 
from  the  schema  and  all  links  to  other  master  and  variable  files 
were  removed ( Requi rement  1.2,  Appendix  F) . 

The  other  major  change  to  the  database  took  place  late  in 
the  1985  spring  quarter.  The  field  length  of  the  class  field  was 


originally  6  and  took  the  form  "EE450  This  configuration 

allowed  for  a  suffix  to  indicate  a  lab  or  special  sessions  of  a 
class.  To  allow  for  compatibility  with  other  database  systems, 
the  field  was  lengthened  to  8  characters  and  now  takes  the  form 
"EENG450  "(Requirement  1.3,  Appendix  F) . 

During  the  course  of  developing  low  level  interface  modules 
to  the  TOTAL  DBMS,  it  was  discovered  that  the  faculty  or  student 
files  could  not  be  deleted  without  destroying  student  thesis 
information.  Since  the  thesis  information  is  usually  kept  for 
research  this  presented  a  problem.  At  the  same  time,  duplicate 
information  was  found  in  the  Master  Thesis  Catalog  (NTIC) .  To 
solve  the  problem,  the  thesis  information  was  moved  from  the 
variable  file  to  the  Thesis  Master  File  (THES)  and  the  Thesis 
catalog  file  should  be  removed  from  the  schema  (Requirement  1.4, 
Append i x  F ) . 


Functional  Requirements 
Functional  File  Grouping 

The  file  structure  of  the  AFIT/EN  Database  (Appendix  A),  as 
proposed  has  16  master  files  and  21  variable  files  but  all  of 
these  files  can  be  group  into  the  following  categories: 

1.  Faculty  :  The  files  that  belong  in  this  group  are 
the  Faculty  Master  file,  and  the  Master  Department  File  and  all 
related  variable  files. 

2.  Student  :  The  files  that  belong  in  this  group  are 
the  Student  Master  file,  the  Master  Section  Number  file,  and  the 
associated  variable  files. 

3.  Course/Room:  The  files  that  belong  in  this  group  are 
the  Master  Course  File,  Master  Quarter  file,  Master  Book  File, 
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Master  Order  File,  Master  Class  Time  File,  Master  Building/Room 
File,  Master  Room  Capacity  File,  Master  Day  Scheduling  File,  and 
associated  variable  files. 

4.  Thesis:  The  file  that  belong  in  the  Thesis  grouping 
are  the  Master  Thesis  Catalog  Number  File,  the  Master  Thesis 
Number  File,  and  associated  variable  files. 

5.  Sequence/Degree  Requirements:  This  grouping  contains 
the  Master  Sequence  File,  the  Master  Degree  Requirements  File, 
and  associated  variable  files. 

This  grouping  is  necessary  to  allow  for  update  priviledges  to 
related  files  within  a  module  and  to  reduce  the  amount  of  code 
required  to  operate  any  application  program.  A  complete 
description  of  the  master  files  and  associated  variable  files  can 
be  found  in  Appendix  A  of  this  document.  Therefore,  the 
requirement  exist  that  the  database  system  be  in  a  modular  and 
structured  form  keeping  related  functions  in  seperate  modules. 

The  structure  of  the  database  file  system  allows  for  this.  The 
following  requirements  exist  for  the  overall  system  to  conform  to 
a  structured  design,  ease  of  maintenance,  and  to  to  insure 
database  integrety  and  security  (Requirement  2.1,  Appendix  F)  : 

1.  Each  functional  group  of  files  must  have  a  standard  set 
of  functions  associated  with  each  file  and  variable  file  if  one 
is  required.  These  function  must  include  the  ability  to  add 
records  or  information,  delete  records  or  information,  update 
database  information,  and  the  ability  to  review  the  information 
stored  in  the  files.  All  information  within  a  database  is 
eligible  for  update  except  the  items  used  as  keys.  If  a  key  is 
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found  to  be  in  error  then  the  entire  record  must  be  deleted  and 
then  added  again  to  maintain  the  integrity  of  the  database. 

2.  Each  functional  group  of  files  must  be  maintained  by  a 
seperately  compiled  and  completely  autonomous  program.  This  will 
keep  memory  requirements  to  a  minimum,  help  the  database  manager 
to  maintain  the  integrity  of  the  data  by  excluding  users. from 
access  to  unauthorized  modules,  and  ease  in  maintenance  of  the 
system 

3.  The  software  design  will  follow  a  top  down  structured 
approach  but  with  a  standard  set  of  utility  subroutines  that 
perform  common  functions  among  the  modules  such  as  signing  off 
and  on  the  database,  error  routines,  reading,  writing,  and 
deleting  records  from  the  database,  and  standard  messages.  This 
will  permit  the  database  to  be  further  abstacted  while  adding 
validity  and  reliability  to  the  software. 

Requi red  Standard  Database  Functions 

To  maintain  any  database,  certain  standard  functions  are 
required  (Requirement  2.2,  Appendix  F) .  In  addition,  many  other 
functions  are  required  that  are  unique  to  the  TOTAL  database 
system.  This  section  will  describe  the  requirements  of  these 
functions  in  detail. 

Each  master  file  must  have  the  ability  to  add,  update, 
delete,  and  review  the  information  within  a  given  record. 
Selecting  these  records  should  be  done  via  a  unique  key  as 
described  in  the  database  record  in  Appendix  C  and  the  routines 
for  these  records  are  described  in  Appendix  G.  The  file 
functions  are  described  below: 

1.  ADD:  Adding  a  master  or  variable  record  to  a  file.  The 
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information  should  be  edited  for  the  proper  syntax  and 
compatibility  with  other  data  items.  Typing  should  be  kept  to  a 
minimum  and  the  user  should  be  allowed  to  select  from  groups  of 
items  to  enter  rather  than  typing  in  the  data.  This  will  keep 
keystroke  errors  to  a  minimum  and  aid  in  the  integrity  of  the 
database . 

2.  UPDATE:  Changing  the  information  within  a  given  record 
of  a  file.  This  function  will  allow  the  user  to  modify  fields 
within  a  record  except  the  record  key.  If  the  record  key  is 
found  to  be  in  error  than  the  record  must  be  deleted  and  added 
with  the  proper  key.  As  in  the  ADD  function,  typing  should  be 
kept  to  a  minimum  and  the  user  should  be  allowed  to  select  from  a 
group  of  items  to  enter  to  keep  the  error  rate  down.  The  same 
syntax,  range,  and  compatibility  checks  should  be  used  in  the 
update  that  were  used  in  the  ADD  function. 

3.  DELETE:  Remove  a  record  from  a  master  and  variable 
files.  This  function  will  permit  the  authorized  user  to  remove  a 
record  from  the  database  system.  The  user  should  select  the 
record  from  a  list  of  keys  and  be  permitted  to  review  the  record 
before  deletion.  The  system  shall  prompt  the  user  to  insure  that 
the  record  shown  is  the  one  to  be  deleted.  After  deletion,  the 
record  should  be  stored  to  provide  for  restoring  the  data  in  case 
of  user  error . 

4.  REVIEW:  This  function  will  display  the  data  within  a 
specified  record  or  series  of  records.  A  great  deal  of 
flexibility  can  be  installed  in  this  function.  However,  care 
must  be  take  to  keep  the  function  as  standard  for  each  of  the 


file  groupings  as  possible  to  make  the  system  easier  to  use.  The 
ability  to  create  a  hardcopy  of  the  data  shall  also  be  an  option 
associated  with  this  function. 


System  Li mi tations/Constraints 

The  limitations  on  the  system  are  really  assumptions  as  to 
the  number  of  students,  faculty,  books,  classes.  These  will  be  made 
to  aid  in  defining  the  storage  capacity  needed  to  run  the  system 
and  the  size  of  the  programs.  These  requirments  must  be  defined 
when  generating  the  database.  This  is  an  important  aspect  of  the 
system  that  was  given  little  attention  in  other  theses  efforts. 

The  following  limitations  apply  to  data  items  or  records  within 
the  database  system  and  are  based  on  current  AFIT  figures 
(Requirement  2.3f,  Appendix  F ) : 

1.  Faculty  Requirements:  According  to  the  faculty  and  staff 
roster  maintained  in  AFIT/ENA,  there  are  over  130  instructors, 
staff  members,  adjunt  professors,  and  lecturers.  This  number 
does  not  include  the  secreteries  and  support  personnel.  Room 
should  be  allotted  for  200  people  to  allow  for  growth  and 
additional  personnel.  Each  faculty  record  requires  460  bytes  of 
storage  space,  so  92,000  bytes  of  storage  will  be  required  to 
store  all  of  the  AFIT/EN  faculty. 

2.  Student  Requirements:  As  of  the  writing  of  this  thesis, 
there  are  532  students  enrolled  in  the  School  of  Engineering 
according  to  AFIT/ENA  rosters  which  includes  part  time  and 
foreign  students.  To  allow  for  expansion  of  the  near  future,  the 
number  of  records  allocated  for  students  should  be  585,  which  is 
ten  percent  greater  then  the  number  currently  enrolled.  This 
number  assumes  that  when  a  student  leaves,  his/her  records  are 

2-9 


^yy 


yyy 


■-.u-WuVu^  l 


V,"v 


•jj.UL.Ii.WlvV'.au.' 


[  Mil  i  -  I1,! 


■v-v-; 


Av'  vw.-.  i-  ^ 


v  -  * 


archived  and  removed  from  the  current  database.  The  logical 
record  size  for  the  student  file  is  460  bytes  of  memory,  which 
means  that  269,100  bytes  of  storage  must  be  reserved  to  hold  the 
master  student  file.  When  allocating  the  space  for  a  student, 
we  must  remember  that  for  each  student  there  are  several  variable 
files.  They  are  the  Variable  Awards  File  (VHAW) ,  Variable  Course 
File  (CRSE) ,  Variable  Education  File  (VEDU) ,and  the  Variable  AFIT 
Courses  and  Credits  File  (VCQR) 

3.  Department  Requirements:  There  are  currently  five 
departments  within  the  school  of  Engineering:  Aeronautical  and 
Astonautical ,  Mathematics,  Electrical  and  Computer  Engineering, 
Physics, and  Operational  Research.  Space  should  be  made 
available  for  seven  departments  to  include  those  of  the  staff  and 
faculty  plus  any  additional  departments  added  at  a  later  date. 

The  space  required  for  this  master  file  is  40  bytes  or  280  bytes 
total  required  to  store  all  of  the  departments  on  disk. 

4.  Thesis  Catalog  Requirements:  This  is  a  difficult 
requirement  to  specify  because  it  is  unknown  if  all  theses  will 
be  required  to  be  cataloged  or  just  the  ones  whose  students  are 
currently  enrolled.  Since  all  theses  are  cataloged  in  the 
library,  it  would  be  a  duplication  of  effort  to  catalog  them  in 
the  database,  however,  the  ability  to  call  up  a  past  thesis  or 
search  the  database  for  a  particular  thesis  would  be  a  powerful 
management  tool.  For  the  time  being,  space  will  be  reserved  for 
those  thesis  whose  students  are  currently  enrolled.  The  decision 
to  catalog  all  theses  will  be  made  at  a  later  date.  A  seperate 
system  could  be  used  to  catalog  past  theses  that  would  be 


available  in  the  library  for  student  use  and  updated  on  a 
quarterly  basis. 

5.  Class  Section  Requirements:  Within  each  department, 
there  can  exist  several  types  of  degrees.  Each  type  of  degree 
will  have  associated  with  it,  a  class  of  students.  Currently, 
there  are  15  different  types  of  degrees  awarded  at  the  AFIT 
School  of  Engineering.  However,  at  any  one  time  there  may  be  two 
sections  overlapping  for  a  certain  degree.  Space  must  be  reserved 
for  30  sections  which  equates  into  1500  bytes  of  storage.  This 
assumes  that  a  sections  data  will  be  archived  upon  the  sections 
graduation . 

6.  Course  Requirments:  According  to  the  AFIT  1985-1986 
catalog,  there  are  493  courses  offered  in  the  AFIT  School  of 
Engineering.  The  faculty  strives  to  keep  AFIT  and  its  courses  up 
to  date  with  the  state  of  the  art  technology.  For  this  reason, 
this  file  will  be  higly  volatile.  Course  are  continuously  being 
added,  deleted,  or  cnanged.  It  is  expected  that  the  database 
will  be  regenerated  on  an  annual  basis,  so  the  requirement  to 
store  493  courses  plus  ten  percent  (542)  should  be  sufficient. 
Since  1218  bytes  are  required  to  store  a  course  record,  69,376 
bytes  are  required  to  store  all  of  the  records  for  one  year. 

7.  Class  Quarter  Requirements:  It  is  expected  that 
information  on  quarters  should  be  maintained  for  one  year 
previous  to  the  current  quarter  and  2  years  in  advance  of  the 
current  quarter  for  a  total  of  3  years  or  12  quarters.  Each 
Master  Quarter  record  requires  40  bytes,  so  480  bytes  should  be 
allocated  for  the  Master  Quarter  File. 

8.  Course  Book  Requirements:  The  average  number  of  books 


required  for  a  course  is  between  1  and  2.  This  exact  average  is 
difficult  to  come  by  because  of  the  volatile  nature  of  the 
courses  and  instructors.  For  the  purposes  of  this  thesis,  we 
will  assume  that  no  more  than  two  books  will  be  required  for  a 
class.  With  the  number  of  courses  set  at  542,  storage  must  be 
set  aside  for  1084  records.  This  equates  into  140,920  bytes  of 
storage  required. 

9.  Daily  Class  Time  Requirements:  For  the  purpose  of  this 
thesis,  we  will  assume  that  classes  start  on  the  hour  with  the 
first  class  starting  at  0800  hours  and  that  last  class  starting 
at  1700  hours.  This  is  a  total  of  10  class  times.  However,  each 
quarter  there  are  a  number  of  special  instances  where  class  times 
do  not  conform  with  this  standard.  To  accomodate  special 
requests,  an  additional  5  records  shall  be  allocated  for  class 
start  times  that  do  not  begin  on  the  hour  and/or  are  outside  the 
0800  to  1700  range.  Each  class  time  requires  20  bytes  of  storage 
for  total  of  300  bytes  required  for  the  total  file. 

10 .  Bui Id ing/Room  Requirements:  Capacity  for  each  room  will 
be  set  at  30  which  is  the  default  enrollment  value.  Currently, 
classes  are  scheduled  for  buildings  640  and  641.  The  number  of 
rooms  vary  from  quarter  to  quarter.  Initially,  the  limit  will  be 
set  to  100  rooms  total.  With  each  record  requiring  32  bytes  of 
storage,  3200  bytes  will  be  reqiured  to  store  the  required 
building/room  records. 

11 .  Degree/Sequence  Requirements:  This  is  also  a  very 
volatile  file  because  of  the  changing  degree  requirements  and  the 
flexibility  given  the  students  and  instructors  when  selecting  a 
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degree  and  sequence.  For  this  purpose  the  sequences  will  have  a 
number  from  0  thru  999/  and  the  degrees  will  have  a  number  from  0 


thru  99.  The  Master  Sequence  file  will  require  60/000  bytes  to 
store  the  maximum  number  and  the  Master  Degree  File  will  require 
6600  bytes  to  store  the  maximum  number  of  degrees. 

Regui red  Response  Time 

Because  of  the  size  of  the  system  and  the  fact  that  other 
programs  will  be  running  on  the  system  at  the  same  time,  the 
issue  of  response  time  will  remain  flexible.  However,  it  will  be 
important  to  keep  response  time  to  a  minimum  to  prevent 
psycological  stepdown{5).  If  the  system  does  not  respond  to  the 
user  within  five  to  eight  seconds  then  the  user  becomes  unsure  of 
what  is  happening  to  the  system.  With  this  in  mind,  the  system 
should  not  be  allowed  to  go  for  more  than  eight  seconds  (5) 
without  reassuring  the  user  that  the  system  is  still  working  on 
their  problem  (Requirement  2.4,  Appendix  F) . 

Required  Repor ts 

For  future  requi remen ts , sever al  additions  to  the  basic 
system  have  already  been  suggested  by  some  faculty  members  and 
students  (Requirement  2.5,  Appendix  F) .  The  first  of  these  is  a 
package  to  generate  the  Division  Faculty  Schedule  and  Manpower 
Requirement  Expenditure  Document  using  the  information  contained 
in  the  database.  The  basic  understanding  of  the  document,  the 
formulas  and  the  concept  were  derived  from  Dr.  Gary  Lamont. 
Interviews  from  Dr.  Biezad  (Lt  Col,  USAF)  and  from  Dr  Seward 
(Maj,  USAF)  have  established  the  basic  guidelines  and  needs  for 
the  system.  This  information  will  be  reviewed  to  establish  the 
feasibility  of  including  this  concept  in  the  design.  See 


Appendix  E  foe  examples  of  the  listing  required  and  the  graphic 
bar  chart  report. 

"The  School  of  Engineering  faculty  workload  is 
measured  in  terms  of  quantifiable  activities 
representing  a  measure  of  faculty  productivity  and 
output.  These  activities  include  classroom  courses 
and  lectures,  laboratory  courses,  MS  thesis 
supervision,  and  PhD  dissertation  supervision. 

This  particular  set  of  faculty  activities 
represents  the  quantity  of  educational  output  in  an 
academic  institution.  All  other  activities  such  as 
course  and  program  development,  professional 
development,  faculty  research,  consulting,  etc., 
are  not  easily  quantifiable..  This  second  set  of 
activities  contributes  to  the  quality  of 
educational  output.  Although  the  principal 
function  of  t'  '.s  second  set  is  in  a  supporting 
role,  its  importance  must  not  be  underestimated. 

For  example,  lack  of  adequate  research  time  for  the 
faculty  will  lead  to  the  deterioration  of  academic 
excellence  and  the  loss  of  Air  Force  unique 
courses.  Thus  the  school  dean  has  the 
responsibility  of  striking  a  proper  balance  between 
the  quantifiable  teaching  activities  (  and  their 
efficiency  and  effectiveness)  and  the  non- 
quantifiable  supporting  functions  to  achieve  the 
overall  objectives  for  individual  programs."  (18) 

The  1983  manpower  standards  are  expressed  as  a  set  of 
formulas  in  terms  of  four  workload  factors  XI,  X2,  X3,  X4  where 

XI  =  Contact  hours  for  degree  education. 

X2  =  Contact  hours  for  PCE. 

X3  =  Master's  degree  graduates. 

X 4  =  Doctoral  degree  students  (dissertation  prase  only) 

The  manpower  formulas  obtained  from  the  AFIT/ENG  department  are  shown 
in  figures  2.2  through  2.3 
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Faculty  =  (8068  +  8.008*X1  +  5.530*X2  +  81.48X3  +  217.3*X4)  / 

1742 

Dept  Heads  =  8710/1742  +  5 

Secretar ies=  (7230  +  1.062X1  +  0.7333*X2  +  10.80*X3  + 

28 . 81*  X4) /1742 

Figure  2-2  EN  Manpower  Formulas 

ENS  Faculty  =  (1366  +  8.008*X1  +  81 . 48* X3) /1742 

Other  Dept  Facutly  =  (1676  +  8.008*X1  +  5.530*X2  +  81.48*X3  + 

217. 3*X4)/1742 

ENS  Secretaries  =  (1413  +  1.062*X1  +  10 . 80*X3) /1742 

Other  Dept  Secretaries  =  (1454  +  1.062*X1  +  0.7333*X2  + 

10 . 80*X3  +  28. 81*X4)/1742 

Figure  2-3  EN  Department  Manpower  Formulas 
The  second  enhancement  involves  the  ability  to  generate  a  class 
schedule  using  the  information  in  the  database  and  calling  the 
scheduling  system  already  in  use.  Captain  Michael  Mullennex  was 
given  as  the  point  of  contact  in  the  scheduling  office.  He 
attended  the  EE  646  Database  class  in  the  Winter  of  1985  and 
helped  develop  a  prototype  of  such  a  system.  This  prototype 
built  a  temporary  file  of  the  information  needed  by  the 
scheduling  system  and  relied  upon  the  user  to  initiate  the  job. 
The  initial  requirements  state  that  this  initiation  of  the  class 
scheduler  be  made  from  the  database  system.  The  primary  input  to 
the  scheduling  system  is  the  education  plans  produced  by  the 
students . 


Until  recently,  the  education  plans  were  written  by  the 
students,  checked  for  sequence  and  graduation  requirements  by  the 


students  faculty  advisor,  and  then  input  into  the  system  by  the 
department  secretary.  The  requirement  exist  to  allow  the  student 
to  generate  education  plans  using  the  databaseand  produce  a 
hardcopy  for  their  records.  This  will  relieve  the  burden  on  the 
department  secretary  of  entering  the  education  plans  on  the 
computer.  Udates  to  the  education  plan  will  depend  upon 
department  policy.  A  sample  of  what  the  edplan  report  should  look 
like  can  be  found  in  Appendix  F. 

In  addition  to  the  education  plan  requirements,  there  is  a 
need  for  the  faculty  and  students  to  be  able  to  validate  the 
students  degree  requirements  and  check  to  proper  sequence 
entries.  This  would  be  done  automaticaly  when  the  student  enters 
the  education  plan.  Additionally,  the  program  should  have  the 
ability  to  caclulate  grade  point  averages  on  selected  classes  for 
the  faculty  only.  This  ability  should  be  available  on  hard  copy 
as  well  as  interactively  (2:H-1). 

A  printed  listing  of  currently  enrolled  students  should  be 
made  available  to  authorized  individuals.  The  output  should 
contain  the  number  and  names  of  the  students  programmed  to  take 
all  classes  for  fiscal/calendar  years.  ( 2 : H—  2 ) 

A  listing  should  be  available  of  all  or  partial  lists  of 
course  information  (quarters  course  taught,  instructor,  text 
used,  credit  hours,  title,  and  number).  ( 2 : H—  2 ) 

Data  Syntax  and  Compa t i bi li ty  Checks 

To  insure  that  accurate  data  is  passed  to  the  database 
system,  data  syntax  and  compatibility  checks  must  be  used 
whenever  entering  data  (Requirement  2.6,  Appendix  F) .  The  Forms 
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Management  System  (FMS)  could  be  used  for  this  to  some  degree, 
but  the  majority  of  the  syntax  and  data  compatibility  checks  must 
be  done  by  the  application  software.  For  a  complete  description 
of  data  syntax  and  compatibility  rules  see  Appendix  C. 

Computer  Interface  Requirements 

Defining  what  information  must  be  presented  to  the  user  and 
what  the  user  must  input  to  the  system  is  a  straight  forward 
process.  In  the  case  of  the  AFIT/EN  Student  and  Faculty 
Database  System,  the  information  has  already  been  defined  by 
previous  thesis  efforts.  Up  till  know,  the  requirements 
definition  has  been  confined  to  the  manipulation  of  this 
information  to  achieve  user  goals.  This  section  of  the  chapter 
will  deal  with  the  "human  computer  interface"  (5)  requirements 
definition  (Requirement  3,  Appendix  F) .  This  section  will 
identify  the  targeted  group  of  users  that  will  use  the  system 
most  often  and  come  up  with  a  standard  profile.  Using  this 
profile  as  a  standard,  the  system  can  be  tailored  to  the  react  to 
the  user.  However,  there  are  some  difficulties  in  trying  to 
define  a  stands:  1  user. 

Users  who  try  to  define  a  system  with  the  designers'  goals 
in  mind  can  find  themselves  in  a  predicament,  particularly  when 
one  of  the  following  is  true(14:140) : 

1.  The  system  in  question  is  just  not  definable  by 
" t r ad i t i ona  1 "  means. 

2.  The  system  can  be  defined,  but  the  user  doesn't  know  what 
he/she  wants. 

3.  The  user  knows  what  he/she  wants  but  can’t  articulate  it. 
When  confronted  by  an  undefinable  system,  the  user  is  faced  with 


the  impossible  task  of  defining  what  he/she  wants  without  knowing 
if  it  will  work  or  not  (14:146).  They  must  perform  some  very 
difficult  activities,  such  as  reducing  problem  solutions  to 
functional  terms,  visualilzing  system  components  and  the 
interaction  of  these  components  during  everday  operations,  and 
discriminating  between  alternative  approaches.  Unfortunately, 
the  only  sure  way  to  determine  if  a  system  will  be  acceptable  to 
the  users  is  to  allow  the  user  to  try  system.  Prototyping 
addresses  this  problem  and  will  be  attempted  for  this 
application.  With  fast  prototyping,  construction  of  system  will 
begin  after  a  bare  minimum  of  requirements  are  defined. 

Targe  ted  User  Group 

Pangman  (2:2-5)  described  a  mixed  category  of  possible 
users  for  the  system.  Among  them  are  secretaries,  professors  and 
instructors,  department  administrators,,  and  students.  For  the 
application  of  this  thesis  effort,  the  user  population  will  be 
confined  to  the  student  and  faculty  of  the  Electrical  and 
Computer  Engineering  Department.  This  presents  a  problem  because 
there  is  such  a  varied  background  among  the  users,  including 
educational  experience,  computer  background,  and  even  typing 
abilities.  Figure  2-4  lists  the  characteristics  of  the  chosen 


standard  user"  (Requirement  3.1,  Appendix  F) . 
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1.  Will  be  Between  the  age  of  21  and  55. 

2.  Has  at  least  2  years  of  college. 

3.  Has  either  run  a  word  processor,  computer, 

v:- 

or  typewr iter. 

4.  Will  be  considered  a  casual  user  of  the 

system,  (no  more  than  once  a  week. 

,V.\ 

5.  Will  have  limited  access  to  manuals. 

6.  Will  not  know  many  of  the  abbreviations 

O 

used  in  the  current  database. 

7.  Will  not  have  access  to  Social  Security 

% 

numbers  because  of  the  privacy  act. 

8.  May  not  have  an  American  Social 

$8 

Security  numbers,  (i.e.  foreign  students) 

Figure  2-5  Standard  User  Characteristics 
Database  Prototype  Development 


Normally,  the  first  logical  step  would  be  to  conduct  a  full 
requirements  definition  cycle  before  the  actual  production  of 
code.  However,  because  of  the  vast  amount  of  work  done  by  the 
EENG  6-64  Database  class  and  by  engineer  Robert  Ewing,  there 
exists  a  complex  and  working  prototype  model  currently  being  used 
by  new  students  to  enter  student  ed  plans  onto  the  database 
(Requirement  3.2,  Appendix  F) .  This  creates  a  perfect 
environment  for  feedback  on  the  "user-f r iendliness"  ot  the 
system,  and  has  proven  very  effective  in  designing  useful 
computer  software  software  for  non-computer  personnel. 

"This  quick  and  dirty  system  has  one  purpose,  and 
that  is  to  show  the  users  what  they  are  asking  for 
and  give  then  some  working  knowledge  of  the 
results  that  can  be  achieved  by  the  system  they 
have  defined."  (14:146) 

Other  purposes  include  showing  the  user  alternative  methods 
for  doing  the  same  task  and  at  the  same  time  demonstrating  new 
features  of  the  system.  It  is  important  to  give  the  users 
alternatives  in  describing  there  system. 


This  technique  was  used  by  Mr.  C.  Gerald  Morrison  and  the 
autnor  of  this  thesis  at  the  552  Airborne  Warning  and  Control 
Division  to  design  a  computer  database  system  for  aircraft 
maintenance  and  scheduling  problems.  Mr.  Morrsion  used 
interviews  and  Air  Force  manuals  on  aircraft  maintenance  and 
scheduling  to  come  up  with  a  preliminary  concept  of  the  system. 
Then,  using  a  CROMEMCO  II  computer  and  the  COBOL  language  with  a 
special  display  interface,  he  designed  a  rough  package  that 
displayed  and  accepted  specific  aircraft  information.  After 
showing  this  to  the  commander,  likes  and  dislikes  were  noted  as 
well  as  suggestions  for  future  enhancements.  In  contrast  to 
conventional  programming  technology,  which  restrains  the 
programmer  in  the  interest  of  orderly  development,  fast  prototype 
development  of  systems  must  amplify  the  programmer  or  analyst  in 
the  interests  of  maximizing  his  effectiveness.  This  can  require 
a  small  number  of  programmers  to  make  essentially  arbitrary 
transformations  to  very  large  amounts  of  code  (6:23).  However, 
the  systems  analyst  or  designer  must  be  ready  to  discard  the 
prototype  and  start  designing  the  system  from  scratch. 

To  gain  further  insight  into  the  needs  of  the  user, 
interviews  will  be  conducted  to  gain  the  thoughts  of  personnel 
who  are  not  familiar  with  the  AFIT/ENG  Database  System.  The 
targeted  group  will  be  the  new  GCS-86D  and  GE-86D  students  who 
arrived  in  May  of  1985.  These  students  are  required  to  enter 
their  education  plan  via  the  ISL  VAX  11/780  using  the  TOTAL 
Database  Management  system  and  the  education  plan  software 
developed  by  engineer  Robert  Ewing.  Students  will  be  questioned 
as  to  whether  they  thought  the  system  was  easy  to  use,  self 


documenting,  and  useful. 

After  interviewing  each  student  personally,  they  will  be 
interviewed  as  a  group  in  hopes  that  ideas  and  comments  from 
other  students  will  spark  conversation  and  ideas  from  others.  It 
is  very  important  to  gain  this  information  in  the  early  stages  of 
the  design  because  the  EDPLAN  system,  as  developed  by  engineer 
Robert  Ewing,  will  be  used  as  a  prototype  for  further  design 
considerations  and  to  add  standardization  to  the  system.  These 
interviews  will  help  in  gaining  useful  information  in  formulating 
the  degree  requirements  portion  of  the  database.  The  suggestions 
of  the  students  will  be  assembled  and  scrutinize  to  ascertain 
their  usefulness. 

Interview  Results 

Fifteen  out  of  the  thirty  students  who  used  the  system  were 
questioned  as  to  their  likes  and  dislikes  of  the  education  plan 
database  prototype.  An  informal  interview  was  performed  because 
of  the  nature  of  the  questions.  The  main  objectives  behind  the 
interview  was  to  find  out  how  easy  the  system  was  to  use,  how 
long  it  took  them  to  learn  to  use  it,  how  "user-friendly”  it  was, 
which  features  they  liked  ,  and  what  they  did  not  like  about  the 
system . 

The  program  itself  was  designed  to  be  self  documenting. 

Once  a  user  logged  on,  the  program  was  executed  and  the  user  was 
prompted  for  specific  answers  to  questions.  Almost  all  of  the 
students  were  able  to  use  the  system  within  a  couple  of  minutes, 
however,  several  of  the  students  who  were  not  familiar  with 
computers  had  difficulty  in  changing  typing  errors.  Once  a  field 


was  typed  in  and  the  user  had  moved  on  to  the  next  field,  many 
had  difficulty  in  backing  up  to  the  previous  field.  Most  of 
them,  re-entered  the  program  and  started  the  process  over  again. 
This  created  many  extra  copies  of  the  edplan  being  printed  off  at 
the  laser  printer. 

The  edplan  program  approached  the  problem  of  entering  data 
via  the  standard  approach.  The  student  was  required  to  know 
which  class  he/she  was  supposed  to  enter,  if  the  class  was  given 
in  a  specific  quarter,  if  the  class  belonged  in  the  sequence 
selected,  or  even  if  the  class  existed.  This  required  a  great 
deal  of  typing  and  chance  for  error.  However,  very  few  of  those 
individuals  interviewed  selected  this  as  a  problem  area.  Most 
excepted  this  as  a  normal  way  of  doing  business,  except  a  few 
students  who  were  not  familiar  with  these  procedures  and  some  who 
were  exceptionally  skilled  in  software  development. 

Some  of  the  suggestions  made  by  the  students  and  the  faculty 
were  on  the  "user-friendliness”  of  the  system.  It  was  noticed  by 
several  students  that  many  of  them  were  entering  education  plans 
that  were  very  similar.  Many  had  selected  specific  degree 
sequences  that  required  the  same  classes.  It  was  suggested  that 
default  edplans  be  made  part  of  the  system  so  a  student  could 
declare  a  sequence  and  update  an  edplan  instead  of  creating  a  new 
one.  The  other  suggestion  was  to  have  the  students  select 
classes  from  a  list  instead  of  typing  them  in,  or  at  least 
provide  an  edit  check  of  the  classes  before  the  database  is 
updated  (Requirement  3.4,  Appendix  F) . 
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Summary 


This  chapter  characterized  the  AFIT/EN  departments 
requirements  for  a  complete  and  integrated  database  system  and 
outlined  the  steps  taken  in  the  preliminary  design  and  source 
test  of  the  proposed  system.  Although  the  requirements  of  the 
system  will  continue  to  change  as  more  data  is  needed,  as  the 
school  grows,  and  as  new  data  becomes  available,  the  importance 
of  a  good  requirements  definition  phase  will  be  evident  in  the 
design  phase.  The  requirements  have  called  for  a  system  that  can 
be  easily  expanded  and  maintained  by  the  faculty  and  student 
body.  In  addition,  the  system  will  be  designed  to  accomodate  the 
"casual  user"  of  the  system  such  as  new  students  and  instructors. 
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III.  Database  Design 

In  chapter  2,  the  requirements  for  the  AFIT/EN  student  and 
faculty  database  system  have  been  well  defined  through  several 
iterations  of  the  requirements  definition  phase  by. this  and 
previous  thesis  efforts.  This  chapter  will  present  the 
preliminary  and  detailed  design  phase  of  the  application  software 
for  the  AFIT/EN  Student  and  Faculty  Database  System.  The 
preliminary  design  phase  is  sometimes  referred  to  as  a  high-level 
design  or  system  model  showing  what  the  system  will  accomplish  in 
its  task,  but  not  specifically  how  it  will  be  done.  (4:12)  In 
this  portion  of  the  design,  system  flowcharts  are  of  use  to 
present  the  system  in  an  abstract  pictorial  form.  The 

preliminary  design  should  also  be  in  such  a  form  as  to  make  it 

independent  of  machine  and  programming  language.  On  the  other 
hand,  the  detailed  design  of  this  system  will  take  the 

preliminary  design  and  refine  it  to  the  point  where  it  can  then 

be  implemen ted 'on to  a  particular  machine  using  a  particular 
language.  There  should  be  a  logical  mapping  from  the 
requirements  definitions  to  the  preliminary  design  and  then  to 
the  detailed  design  of  the  system.  It  is  important  at  this  point 
to  continue  to  review  the  requirements  of  the  system  for  errors 
and  feasibility. 

The  design  of  the  system  will  follow  the  top-down  structured 
approach  to  software  design.  Structured  design  is  a  set  of 
proposed  general  program  design  considerations  and  techniques  for 
making  codeing,  debugging,  and  modification  easier,  faster,  and 
less  expensive  by  reducing  complexity.  (14:328)  Simplicity  of 


design  will  be  the  major  theme  when  dividing  the  system  into 
seperate  pieces.  To  reduce  the  complexity  even  more,  some  of  the 
linked  lists  that  are  to  be  used  as  a  data  structure  and  the 
database  system  TOTAL  will  have  operations  defined  on  them  to 
improve  the  interface  between  the  application  programmer  and  the 
database  system. 

In  this  chapter,  the  schema  will  be  reviewed  to  define  and 
identify  the  relations  that  were  built  into  the  database  system. 
The  requirements  of  the  system  defined  in  chapter  two  will  then 
be  mapped  into  the  preliminary  design  of  the  overall  system. 
Finally,  the  preliminary  design  of  the  database  system  will  be 
refinded  and  further  defined  into  the  detailed  design  of  the 
sytem  in  two  seperate  categories.  The  first  category  will  be 
the  functional  design  of  the  system  and  the  second  will  include 
the  design  of  the  interface  to  the  system.  Sometimes,  these 
steps  of  the  software  development  phase  are  considered  as  well 
defined  steps  with  absolute  borders  on  the  definition  of  each 
phase.  In  this  application  of  the  waterfall  model  of  software 
development,  the  process  becomes  more  of  an  evolution  of 
development  where  one  phase  transitions  to  the  next  with  no 
distinct  border. 


Database  Relationships 

It  was  obvious,  upon  review  of  the  database  schema  for  the 
AFIT/EN  database  system,  what  some  of  the  relationships  and 
applications  were  invisioned  by  the  original  creators  of  the 
database.  Many  of  the  characteristics  of  the  database  schema 
appear  to  take  on  the  traits  of  a  relational  database  system  but 


still  maintain  the  complexity  and  speed  of  a  network  database. 
Each  database  relation  will  be  examined  for  some  of  the 


relationships  suggested  by  faculty  members  and  students  and  there 
apparent  application  in  the  design  of  the  database  software. 

These  applications  will  then  be  fit  into  the  overall  design  of 
the  system  later  in  the  chapter. 

The  student  and  faculty  master  files  are  linked  by  common 
variable  files.  Figure  3-1  gives  a  list  of  the  master  files  and 
variable  files  along  with  there  respective  file  codes.  Each 
student  and  faculty  member  share  common  information  in  the 
Variable  Honors  and  Awards  File,  Section  File,  Advisor  File,  and 
Thesis  File.  Figure  3-2  shows  the  database  relationship  to  these 
two  files.  These  relationships  allow  the  application  programmer 
to  extract  certain  information: 

1.  Select  a  complete  or  partial  list  of  all  of  the  students 
who  have  the  same  faculty  advisor,  thesis  advisor,  and  committee 
member  (  Figure  3-3)  . 

2.  Select  the  students  and  faculty  who  have  attended  the 
same  university  and  achieved  the  same  degree. 

3.  Retrieving  information  on  the  section  adivisor  and 
section  leader  for  any  given  student  (Figure  3-4). 

4.  Calculating  the  work  load  on  an  instructor  by  extracting 
the  number  of  students  he/she  advises  on  thesis  and 

di sser tations . 

5.  Select  and  print  all  of  the  students  who  have  signed  up 
for  the  same  class. 

6.  Retrieve  the  courses  an  instructor  is  teaching,  or  has 
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taught  list  thesis  students  he/she  advises. 


MASTER  FILES 


FACT 

MASTER 

FACULTY  FILE 

DEPT 

MASTER 

DEPARTMENT  FILE 

STDT 

MASTER 

STUDENT  FILE 

THES 

MASTER 

THESIS  NUMBER  FILE 

SECT 

MASTER 

SECTION  NUMBER  FILE 

MCRS 

MASTER 

COURSE  FILE 

MQTR 

MASTER 

QUARTER  FILE 

MBKT 

MASTER 

BOOK  FILE 

MORD 

MASTER 

ORDER  BOOK  FILE 

TIME 

MASTER 

CLASS  TIME  FILE 

BLRM 

MASTER 

BUILDING/ROOM  FILE 

CPTY 

MASTER 

ROOM  CAPACITY  FILE 

DAYS 

MASTER 

DAY  SCHEDULING  FILE 

MSSF 

MASTER 

SEQUENCE  FILE 

MDEG 

MASTER 

DEGREE  REQUIREMENTS  FILE 

VARIABLE  FILES 


VEDU  VARIABLE  EDUCATION  FILE 

FSOC  VARIABLE  FACULTY  SOCIETY  FILE 

FCMT  VARIABLE  FACULTY  DEPARTMENT  AND 

COMMITTEE  MEMBER  FILE 
VHAW  VARIABLE  HONORS  AND  AWARDS  FILE 

FINT  VARIABLE  FACULTY  INTERESTS  FILE 

FCOM  VARIABLE  FACULTY  PUBLICATIONS  AND 

PRESENTATIONS  FILE 
FTDY  VARIABLE  FACULTY  TDY  FILE 

MCRS  VARIABLE  STUDENT  COURSE  FILE 

THTL  VARIABLE  THESIS  TITLE  FILE 

SECL  VARIABLE  SECTION  LEADER  FILE 

VCQR  VARIABLE  QUARTER  FILE 

VREQ  VARIABLE  PRE-REQUISITE  FILE 

VCBK  VARIABLE  BOOK  LINK  FILE 

VNMO  VARIABLE  NUMBER  ORDERED  FILE 

SCHD  VARIABLE  CLASS  SCHEDULE  FILE 

CLSR  VARIABLE  CLASSROOM  FILE 

TCMT  VARIABLE  THESIS  COMMITTEE  MEMBER  FILE 

FADV  VARIABLE  FACULTY  ADVISOR  FILE 

VINS  VARIABLE  INSTRUCTOR  STATISTICS  FILE 

TADV  VARIABLE  THESIS  ADVISOR  FILE 

VPDQ  VARIABLE  PROFESSIONAL  DEVELOPMENT  FILE 

VMSS  VARIABLE  SEQUENCE  FILE 


Figure  3-1  Master  and  Variable  File  list 
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DATABASE  SCHEMA  (STUDENT) 


HDEG 


I10RD 


The  Master  Course  File  schema  has  the  potential  to  provide  a 
great  deal  of  information  to  the  user  of  the  system.  Figure  3-5 
contains  the  basic  relationship  of  the  Master  Course  File  schema. 
Each  course  is  linked  to  a  variable  quarter  file  which  contains  a 
series  of  records  that  designates  when  the  course  is  offered  and 
the  Variable  Schedule  File  which  contains  information  as  to  when 
and  where  the  course  is  given.  Linked  via  the  schedule  file  is 
the  Master  Class  Time  file  and  the  Master  Day  file.  Using  these 
relations,  some  of  the  applications  are: 

1.  When  updating  information  on  a  course,  there  is  only  a 
need  to  change  it  in  one  location  which  makes  the  change  global 
thoughout  the  entire  database. 

2.  The  database  can  be  searched  to  examine  the  text  books 
required  for  that  course,  the  availability  of  those  books,  and 
the  price  of  them. 

3.  The  database  can  be  searched  to  determine  what  classes 
are  offered  during  a  ceratain  day  and/or  time.  This  would  be 
useful  for  a  student  who  is  looking  to  replace  a  dropped  class. 

The  sequence  and  degree  requirements  schema  gives  the 
faculty  the  ability  to  verify  whether  a  student  meets  the 
requirments  for  a  specific  degree  and  sequence  within  a 
department.  The  Master  Sequence  File  and  the  Master  Degree 
Requirement  File  are  linked  through  the  Variable  Sequence  File. 
Using  these  relationships,  the  faculty  will  no  longer  need  to 
check  a  students  education  plan  to  insure  graduation  requirements 
for  a  course  sequence  are  met.  The  database  can  also  be  used  to 
calculate  the  students  eligibility  for  graduation. 


PRELIMINARY  DESIGN 


The  preliminary  design  phase  of  the  software  development 


life  cycle  bacically  takes  the  requirements  as  defined  in  the 


requirements  definition  and  maps  these  into  a  abstract  picture  of 


the  system.  At  this  stage  in  the  development  life  cycle,  system 


flowcharts  and  diagrams  play  an  important  part  in  depicting  the 


system.  Appendix  D  contains  all  of  the  system  structure  charts 


referenced  in  this  chapter.  Each  requirement  will  be  implemented 


in  the  design  of  the  system  (if  applicable)  and  justified.  To 


evaluate  alternatives  for  dividing  programs  into  modules,  it 


becomes  necessary  to  examine  and  evaluate  types  of  "connections" 


between  modules.  A  connection  is  a  reference  to  some  label  or 


address  defined  elsewhere  outside  the  module  (15:329).  When 


designing  the  system,  it  will  become  important  to  group  modules 


together  that  are  functionally  rela'.?d  into  a  common  seperately 


compiled  program,  and  define  operations  on  these  groupings. 


Main  Program  Module  Design 


Because  of  the  database  schema  and  previous  specifications 


in  chapter  2,  there  exists  a  requirement  for  the  database  system 


to  be  in  a  structured  form  and  for  the  five  fi!.e  groupings  to  be 


contained  in  separately  compiled  programs.  Appendix  D  has  the 


system  diagram  for  the  five  main  functional  groupings  that  are 


named  STDTMOD ,  FACTMOD,  MCRSMOD , THESMOD ,  SEQUMOD.  These  modules 


will  perform  the  following  functions: 


1.  STDTMOD:  Maintain  the  Student  Master  File,  Honors  and 


Awards  file,  Student  Course  File,  and  the  Sequence  File  through 


standard  add,  update,  delete,  and  review  routines.  The  only 


mm* 


05 
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exception  is  that  students  may  not  have  access  to  grade  changes. 
This  must  be  done  by  a  seperate  module  £or  security  reasons. 
Students  should  only  have  access  to  their  education  plans  and 
personal  data  while  maintaining  the  ability  to  update  their 
locator  card  on  the  computer. 

2.  FACTMOD:  Maintain  the  Faculty  Master  File,  Society  File, 
Faculty  Advisor  File,  Section  File,  Department  and  Committee 
Files,  Honors  and  Awards  File,  Publications  and  Presentation 
File,  TDY  File,  and  the  Instructor  Statistics  File. 

3.  MCRSMOD:  Maintain  the  Master  Course  File,  Master  Quarter 
File,  Master  Book  File,  Master  Order  File,  Master  Class  Time 
File,  Master  Building/Room  File,  Master  Room  Capacity  File, 

Master  Day  Scheduling  File,  Variable  Quarter  File,  Variable 
Requisite  File,  Variable  Book  Link  File,  Variable  Number  Ordered 
File, and  Variable  Classroom  File.  Modules  to  add  master  files, 
delete  file,  update  files  and  review  files  will  be  included 
within  this  module. 

4.  THESMOD:  Maintain  the  Master  Thesis  Number  File,  Variable 
Thesis  Title  File,  Variable  Thesis  Committee  Member  File,  and 
Thesis  Advisor  File. 

5.  SEQUMOD:  Maintain  the  Master  Sequence  File,  Master  Degree 
Requirement  File  and  Variable  Sequence  File.  These  Files  will  be 
maintained  with  add,  delete,  update,  and  review  modules.  Because 
of  the  changing  requirements  within  the  departments,  these  files 
will  are  seperated  from  the  associated  course  module.  Faculty 
and  students  should  be  allowed  to  vary  sequences  and  degree 
requirements  to  obtain  maximum  flexibility.  Therefore,  the 


degree  requirements  and  sequences  obtained  are  to  be  used  as  a 
guide  and  not  a  rule. 

Data  and  File  Abstraction 

To  make  it  easier  on  the  user,  the  programmer,,  and  the 
designer,  operations  are  needed  to  act  as  an  interface  between  a 
data  structure  and  the  TOTAL  Database  Maintenance  System.  These 
operations  or  algorithms  must  meet  the  following  criteria  (3:2): 

1.  There  are  zero  or  more  quantities  which  are  externally 
supplied . 

2.  At  least  one  quantity  is  produced. 

3.  Each  instruction  must  be  clear  and  unambiguous. 

4.  When  the  instructions  of  an  algorithm  are  traced,  in  all 
cases  the  algorithm  will  terminate  after  a  finite  number  of 
steps . 

5.  Every  instruction  must  be  sufficiently  basic  that  it  can 
in  principle  be  carried  out  by  a  person  using  only  a  pencil  and 
paper . 

By  using  these  operations  on  the  data  types  and  files,  we  can 
then  control  the  manipulation  of  data  to  such  a  degree  that  we 
can  then  validate  the  algorithms  and  add  to  the  correctness  of 
our  program.  It  is  important  to  note  that  the  operations  on 
these  data  types  and  files  are  descibed  in  terms  of  what  is  done 
but  not  how  the  operation  should  occur.  This  division  of  the 
tasks,  called  specification  and  implementation,  is  useful  because 
it  helps  to  control  the  complexity  of  the  entire  process  (2:7). 

It  is  hoped  that  by  doing  this,  the  further  development  of 
application  software  will  be  made  easier. 
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Each  Master  File  and  Variable  File  will  have  associated  with 


it,  a  group  of  modules  that  act  as  an  interface  to  the  TOTAL 
Database  System.  Each  file  must  have  a  record  described  in  the 
TYPE  declaration  section  with  the  ability  to  make  it  a  linked 
list  if  necessary.  The  Figure  3-6  shows  these  modules  where 
"XXXX"  represents  the  four  letter  file  code.  For  instance, to 
write  to  the  Student  Master  File  ( STDT) ,  the  module 
WRMSTDT ( STDT_RECORD)  would  be  used.  For  a  complete  description 
of  the  common  routines  see  Appendix  H.  These  modules  will  have 
the  following  characteristics: 

1.  Each  module  will  return  a  status  code  which  notifies  the 
calling  routine  of  the  success  or  failure  of  the  database 
operation  . 

2.  Each  module  will  be  responsible  for  transfering  data  from 
the  record  to  or  from  the  database  schema.  The  TOTAL  database 
system  expects  the  data  to  be  entered  as  a  continuous  string  of 
data.  This  attribute  should  be  hidden  from  the  applications 
programmer.  This  is  accomplished  by  defining  the  record  types  in 
the  standard  type  declaration  module  that  all  programs  wil  have 
access  to. 

3.  The  write  to  variable  records  should  handle  the  instance 
where  there  is  more  than  one  master  record  linked  to  the  variable 
record.  It  may  be  difficult  to  define  a  standard  set  of 


variable  record  functions  depending  upon  the  linkage  reference 
and  the  key  of  the  master  record  associated  with  it. 


MASTER  FILE  OPERATIONS 

MODULE 

FUNCTION 

WRMXXXX 

Write  to  a  master  file. 

RDMXXXX 

Read  From  a  master  file  in  a 
random  or  sequencial  manner. 

DLMXXXX 

Delete  a  record  from  a  master 
file. 

ADMXXXX 

Add  a  record  to  a  master  file. 

VARIABLE  FILE  OPERATIONS 

ADCXXXX 

Add  Variable  Continue.  Add 
a  record  after  the  record  that 
is  currently  pointed  to. 
the  string. 

ADAXXXX 

Add  Variable  record  after  the 
second  record  in  the  string. 

ADBXXXX 

Add  Variable  record  before  the 
record  being  pointed  to. 

RDVXXXX 

Reads  the  next  variable  record 
in  the  string. 

RDRXXXX 

Reads  the  previous  variable 
record . 

RDDXXXX 

Read  direct.  Reads  the  record 
directly  pointed  to  by  reference 
pointers . 

WRVXXXX 

Writes  a  Variabel  record. 

DLDXXXX 

Delete  the  current  record  pointed 
to  by  reference  pointers. 

Figure  3-6  Generic  Standard  Database  Procedures 
Throughout  the  database,  there  will  be  many  instances  where 
a  search  will  be  required  on  the  Faculty,  Student,  and  Staff 
files.  Since  these  routines  will  be  used  in  almost  all  of  the 
programs,  it  will  be  important  to  define  them  early  in  the 
development  of  the  system  and  implement  the  procedures  in 
computer  code.  These  list  routines  will  be  used  to  search  for  a 
student  or  faculty  member  by  name  or  section  and  must  be  kept  in 
alphabetical  order  at  all  times.  In  addition,  the  speed  at  which 
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the  lists  ate  searched  and  sorted  are  of  the  utmost  importance  to 
the  user.  The  operations  on  the  list  will  be  defined  as: 

1.  ADDNAME:  Adds  a  faculty  or  students  data  to  the  list  of 
names . 

2.  DELNAME:  Removes  a  faculty  or  students  data  from  the 

list. 

3.  FINDNAME:  Finds  a  faculty  or  student  depending  upon  the 
last  name  and  position  the  search  started  in  the  list. 

4.  CREATE:  Creates  a  empty  list  with  a  header  and  trailer 
record . 

5.  BUILDLINKLIST:  Builds  the  linked  list  of  student  or 
faculty  names  from  reading  the  database  sequentially. 

A  complete  description  of  the  axioms  and  procedure  definitions 
can  be  found  in  Appendix  H. 

Standard  Database  Functions 

Using  the  standard  utilities  that  have  been  created  to 
access  the  database,  the  standard  functions  associated  with  the 
database  become  easier.  Each  master  file  will  be  accessed 
through  a  series  of  menus  and  standard  database  functions.  At 
the  lowest  level  of  access,  each  menu  will  give  the  user  the 
ability  to  add  records,  delete  records,  update  records,  and 
review  records  with  the  option  to  produce  a  hardcopy.  Figure 
3-7  shows  an  example  of  a  menu  used  in  the  Database  Class 


(  EENG646)  . 


COURSE  SEQUENCE  DATABASE  MODULE 


OPTION 

1 

2 

3 

4 

5 
9 


DESCRIPTION 

ADD  A  SEQUENCE 

UPDATE  A  SEQUENCE 

DELETE  A  SEQUENCE 

REVIEW  A  SEQUENCE 

CHECK  A  STUDENTS  SEQUENCE 

EXIT  TO  PREVIOUS  MENU 


SELECT  OPTION  (1-5,9) 


Table  3-7 

Master  Sequence  File  Menu 

The  commercial  frames  system,  from  Digital  Equipment 
Corporation  (DEC)  called  the  Form  Management  System  ( FMS ) ,  will 
be  used  to  produce  all  of  the  displays  seen  by  the  user. 

Appendix  E  contains  the  frames  that  have  been  produced  and  used 
at  the  writing  of  this  thesis.  It  is  designed  for  ease  of 
formulation  and  simulation  in  order  to  collect  the  transmited 
data  in  an  orderly  manner.  3y  using  this  utility, 
standardization  will  be  built  in  the  interface  to  the  database 
from  the  users  point  of  view. 

It  is  important  to  note  that  the  number  "9"  is  used  to  exit 
to  the  previous  menu  instead  of  the  number  "6"  which  would  have 
been  the  next  logical  number  in  sequence.  This  was  done  for  two 
reasons:  1)  The  number  used  to  exit  all  of  the  screens  in  the 
system  will  be  "9"  and  2)  The  remaining  digits  will  be  reserved 


£or  furture  adaptations  to  the  system.  By  standardizing  the 
selection  of  items  in  the  menus,  the  transition  from  using  one 
portion  of  the  system  to  another  should  be  easy. 

See  Appendix  E  for  the  frames  used  in  this  development. 

Database  Generation  and  Initialization 

The  following  procedures  on  generating  and  initializing  the 
AFIT/EN  database  were  taken  from  the  TOTAL  Database  Users  Manual, 
publication  number  pl0-0001-00  with  alterations  to  the  procedure 
by  Mr.  Robert  Ewing.  This  procedure  is  to  be  used  whenever  the 
sizes  of  the  files  or  alterations  in  the  schema  are  to  be 
changed.  See  requirement  number  2.3.1  through  2.3.11  for  file 
size  specifications.  Performing  this  function  allows  the 
Database  Manager  to  change  the  size  of  the  files  to  accomodate  an 
increase  in  students,  faculty,  course,  sequence,  and  theses. 

"The  following  steps  should  be  followed  for 
each  Data  Base  Descriptor  Module ,( DBMOD) ,  the  user 
wishes  to  generate. 

1.  Code  the  input  DBDL  statements  as  described 
in  chapter  4,  the  Data  Base  Generation  chapter  of 
the  TOTAL  Users  Manual. 

2.  The  DBGEN  program  will  accept  a  sequential 
source  file  of  80  bytes  image  records. 

3.  Execute  the  DBGEN  utility.  This  utility 
will  read  the  DBGL  statements  if  required  and  print 
the  data-base  documentation  lilsting  including  all 
diagnostics  and  statistical  messages.  If  an  output 
file  is  required,  it  will  be  created  with  the 
output  filename  given  with  the  extension  .MAC.  The 
following  statements  will  execute  DBGEN  from  a 
terminal  provied  the  user  has  update  priviledges: 

$SET  DEF  DUA3: [TOTAL] 

$  RUN  [TOTAL] DBG 
DBG>AF ITDB , MAC=AF ITDB . DBG 
$MCR  MAC  AFITDB, AF ITDB/-SP=AF ITDB 
$  RUN  DBF 

FMT>  DBMOD  =  AF ITDB 
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The  output  file  will  be  the  name  of  the  .MAC 
file  while  the  input  file  will  contain  the  input 
DBDL.  The  default  extention  for  the  input  file  is 
.DBG.  Upon  completion  of  the  database  generation 
if  errors  are  detected  they  will  be  documented  in 
the  output  listing  at  the  terminal.  The  output 
listing  file  is  not  spooled.  To  spool  the  listing 
file  the  following  step  is  necessary: 

$PRINT  LSTF11 . DBG 

4.  Assemble  the  generated  source  program 
providing  the  DBMOD  object  file. 

5.  The  Data-Base  Descriptor  Module  (DBMOD)  is  now 
available  for  use  with  TOTAL  and  the  utilities. 

To  start  the  database  in  operation,  following 
the  following  VMS  instructions: 

1.  $  SUBMIT  TOTALINIT 

2.  $  RUN  TOTALPRM 

3.  TOT>AFITDB 

4.  TOT>/ 

At  this  point,  all  of  the  files  are  empty  and 
must  be  restored  (16:3-5)" 

Reports  Generations  and  Desian 


Some  of  the  required  reports  listed  below  were  specified  by 
Pangman  (2  Appendix  H  of  his  thesis).  Some  of  these  requirements 
were  specifically  requested  in  the  interviews  conducted  while 
others  reflect  anticipated  requests  by  the  users.  Other  required 
reports  are  a  result  of  recent  interviews  and  requests  by  the 
faculty.  These  reports  are  listed  in  requirement  numbers  2.5.1 
through  2.5.4  of  Appendix  F. 

Requi red  Repor  ts 

1.  Division  Faculty  Schedule  Manpower  and  Requirements 


Expenditure  Document.  (Requirement  2.5.1) 


2.  Faculty  Workload  Distribution  /ENG 

(Requirement  2.5.2) 

3.  Enrolled  Student  Listing  (Requirement  2.5.3) 

4.  Course  Listing  Information  (Requirement  2.5.4) 

5.  Student  Locator  (  Requirement  2.5.5) 

6.  Course  Enrollment 

7.  Education  Plans 

Syntax  .and  Compatibility  Routines 

The  integrity  of  the  data  is  vital  to  providing  management 
with  vital  information.  Requirement  2.6  of  Appendix  F  states  the 
necessity  for  a  complete  list  of  data  syntax  and  compatibility 
tests  to  be  performed  on  the  data  items  when  entered  into  the 
database  system. 

The  TOTAL  database  management  system  handles  many  of  the 
compatibility  routines  and  the  Forms  Management  System  (FMS)  will 
also  handle  many  of  the  syntax  operations.  Items  such  as  rank, 
dates,  AFSC's,  phone  numbers,  race,  religion,  sex,  aero  ratings, 
and  items  entered  as  years  must  be  edited  by  the  the  application 
programs.  See  Appendix  C  for  a  complete  list  of  syntax  and 
compatibility  rules. 


The  detailed  design  phase  of  the  waterfall  model  of  software 
development  will  be  a  refinement  of  the  preliminary  design  to  the 
extent  that  the  detailed  design  can  then  be  implemented  in  a 
computer  language .( 4 : 12)  This  portion  of  the  detailed  design  will 
deal  with  developing  a  strategy  of  building  software  to  perform 
the  required  functions  assigned  to  the  database.  It  involves 
taking  the  logical  design  of  the  system  and  making  it  a  physical 
design  that  can  be  mapped  into  the  implementation  phase.  The 
design  of  the  proposed  system  imposes  layers  of  software 
between  the  user  and  the  machine  itself.  Figure  3-8  identifies 
these  layers. 
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Figure  3-8  AFIT/EN  Software  Layer  Description 


This  part  of  the  chapter  will  take  the  preliminary  design 
steps  and  refine  them  into  the  detailed  design.  The  main  program 
modules  specified  in  the  first  part  of  this  chapter  will  be 
defined  functionally  and  by  means  of  structured  diagrams.  The 
data  and  file  operations  will  be  implemented  and  tested  in  this 
chapter  to  facilitate  the  implementation  of  the  application 
software.  The  standard  database  functions  will  also  be 
implemented  and  tested.  These  two  steps  are  required  to 
construct  the  layer  5  (  Figure  3-8)  of  the  database  in  order  to 
form  a  "user-friendly"  interface  to  the  TOTAL  database  system. 
Each  step  of  the  design  should  relate  to  some  portion  of  the 
requirements  in  Appendix  F. 

Database  Application  Software  Layer  Descr iption 

1.  Layer  1:  This  layer  of  software  consists  of  the  main 
module  routines  and  offers  the  closest  interaction  to  the  user. 
These  modules  present  choices  to  the  user  as  to  what  portion  of 
the  database  they  wish  to  work  with.  (i.e.  FACTMOD,  STDTMOD, 
THESMOD,  MCRSMOD,  SEQUMOD) .  This  layer  may  be  implemented  in  a 
command  file  mode  and  should  check  to  see  if  the  TOTAL  database 
system  is  in  operation. 

2.  Layer  2:  This  layer  is  associated  with  each  of  the  five 
distinct  functional  modules  (requirement  2.1,  Appendix  F) .  These 
modules  will  present  to  the  user  a  choice  of  what  files  or 
information  they  wish  to  modify  (Add,  Update,  Delete,  or  Review) 
or  if  selecting  an  alternative  function  associated  with  the  file 
such  as  the  scheduling  routine,  report  listings,  or  running 
management  information  programs. 
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3.  Layer  3:  This  layer  of  software  will  perform  the  actual 
function  requested  in  layer  2.  The  adding  of  records,  deleting 
of  records,  updates  and  reviews  will  be  part  of  the  software 
required  for  these  modules.  These  layers  are  still  responsible 
for  prompting  the  user  for  information  and  instructions. 

4.  Layer  4.  This  layer  will  be  hidden  from  the  interactive 
database  user.  These  modules  perform  operations  unique  to  the 
functions  of  layer  3.  Some  examples  of  these  would  be  formatting 
a  report  for  course  listings,  syntax  checks  on  the  records  of 
information,  preparing  links  to  select  variable  records,  and 
frames  displays.  In  fact,  any  module  that  is  used  by  only  one 
function  would  be  considered  part  of  this  layer. 

5.  Layer  5:  These  modules  are  standard  routines  that  act  as 
a  "user-friendly"  interface  to  the  TOTAL  Database  System.  Adding 
of  master  records,  reading  master  records,  link  list 
manipulation,  signing  on  and  off,  and  status  checking  are  some  of 
the  routines  required. 

6.  Layer  6:  This  layer  is  the  TOTAL  Database  System  itself. 
This  layer  is  presented  to  the  application  programmer  in  the 
forms  of  DATBAS  subroutine  calls. 

7.  Layers  7  &  8:  These  layers  are  system  software  that 
interacts  with  the  operating  system,  and  the  machine  itself. 

Standard  Database  Module  Descriptions 

Layer  5  of  the  design  of  the  system  allows  the  programmer  to 
have  ease  of  access  to  the  TOTAL  database  system.  3ecause  of  the 
wide  range  of  operations  allowed  by  TOTAL,  a  subset  of  these 
operations  will  be  selected  for  use.  The  justification  of  the 
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The  following  procedures  are  required  as  the  interface  to 
the  AFIT  Database  system  through  TOTAL.  To  operate  these 
procedures,  a  standard  set  of  type  declarations  is  required  to  be 
included  with  any  run  of  the  database. 

1.  PROCEDURE  S IGNONOROFF ( OPER : BUFF 5 ;  DATASET : BUFF4) : 
This  will  log  the  applications  program  onto  the  database.  The 
parameter  passed  to  the  routine  will  identify  which  of  the  five 
main  modules  is  running  and  the  appropriate  schema  which 
idetifies  what  files  can  be  accessed  will  be  loaded.  This  routine 
should  also  log  off  the  application  program  from  the  database. 
Every  program  that  uses  the  database  is  required  to  sign  on  and 
identify  itself  to  TOTAL. 

2.  PROCEDURE  CHECKSTATUS (OK) :  This  procedure  checks  the 
status  of  the  database  call  and  returns  to  the  caller  a  boolean 
variable,  (TRUE  =  Good  database  read,  FALSE  =  Error  in  the  call). 
If  an  error  occurs,  the  checkstatus  routine  should  return  a 
message  to  the  user  of  the  outcome  and  offer  some  diagnostics. 
This  procedure  should  be  called  at  the  end  of  each  DATBAS 
procedure  call. 

3.  PROCEDURE  RDMXXXX(VAR  XXXX  :  XXXX_REC;  KEY: 
typekey) :  This  procedure  will  read  a  master  record  from  the 
database.  The  "XXXX"  is  to  be  replaced  by  the  four  letter  file 
code  of  the  file  as  defined  in  the  database  generation  listing 
(figure  3-1).  The  program  will  format  a  record  of  the  type 
XXXX_REC  with  the  information  passed  in  the  buffer  area.  The 


data  item  "KEY"  will  contain  the  master  key  of  the  record.  This 
procedure  is  required  for  all  master  records  in  the  database. 

4.  PROCEDURE  WRMXXXX (  XXXX:  XXXX_REC) :  This  procedure 
writes  a  record  back  to  the  database  after  an  update  transaction. 
The  information  contained  in  the  record  of  type  XXXX_REC  is 
transferd  into  the  buffer  area  in  the  same  order  the  data 
appears  in  the  record.  This  procedure  is  required  in  only  those 
modules  that  have  update  operations. 

5.  PROCEDURE  ADMXXXX(  XXXX:  XXXX_REC;  KEY:  typekey)  : 
The  add  master  routine  is  used  to  add  a  new  master  record  to  the 
database.  The  operation  is  almost  identical  to  the  WRMXXXX 
except  for  the  function  assigned  to  the  database  call.  This 
routine  is  used  only  by  those  modules  which  are  allowed  to  add 
new  records  to  the  database. 

6.  PROCEDURE  DLMXXXX(  KEY:  typekey):  This  routine 
reads  the  master  record  in  the  update  mode  to  insure  it  is  part 
of  the  database,  if  it  is,  then  the  user  is  prompted  to  insure  he 
wishes  to  delete  the  record.  If  the  record  is  to  be  deleted,  all 
variable  file  links  are  deleted  and  stored  in  a  save  file  in  case 
restoration  is  desired,  and  then  the  master  file  is  deleted  and 
saved . 

Var i able  Data  Se t  Functions 

These  routines  are  a  subset  of  the  functions  permitted  by 
the  TOTAL  database  system.  The  READR  and  ADDVB  operations  were 
omitted  because  combinations  of  the  other  operations  could 
perform  the  same  functions.  Because  of  the  flexibility  of  the 
variable  record  and  the  number  of  links,  and  master  file  keys, 


the  files  that  these  are  to  be  assigned  to  will  be  limited  to 
those  files  with  master  record  lengths  that  have  the  same  key 
length  and/or  have  only  one  variable  link. 


1.  PROCEDURE  ADCXXXX (  XXXX:  XXXX_REC;  KEY:  key type); 
This  routine  will  add  a  variable  record  after  the  variable  record 
currently  pointed  to  by  the  database  pointer. 

2.  PROCEDURE  RDVXXXX(VAR  XXXX : XXXX_REC ;  VAR 
'/REFERENCE:  BUFF4 ; 

CODE : typekey ) ;  This  routine  reads  the  variable  record  from  the 
file  designated  by  the  four  digit  code  "XXXX"  that  occurs  in  the 
next  string  after  the  record  pointed  to  by  the  VREFERENCE 
pointer.  The  information  is  then  formatted  into  the  record 
defined  by  the  record  type  XXXX_REC.  This  routine  is  a  standard 
sequential  read  function  and  will  be  used  in  almost  all 
applications. 

3.  PROCEDURE  RDDXXXX(VAR  XXXX : XXXX_REC ; 

7REFRENCE : BUFF4 ;  CODE:  typekey):  This  routine  will  read  a  record 
iirectly  from  the  database  file  with  the  code  XXXX  pointed  to  by 
the  code  contained  in  the  parameter:  VREFERENCE.  The  information 
will  then  be  formatted  into  the  record  of  type  XXXX_REC  and 
returned  to  the  calling  program.  This  routine  is  useful  in  the 
application  of  updating  a  database  record. 

4.  PROCEDURE  WRVXXXX ( XXXX : XXXX_REC ;  VREFERENCE : BUFF4 ; 
CODE : typekey ) :  The  Write  Variable  record  routine  writes  a  record 
directly  to  the  database  in  the  same  position  it  was  retrieved 
from.  This  record  must  be  read  in  the  update  mode  before  it  is 
written  back  to  the  file.  This  routine  is  useful  in  applications 
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for  updating  the  variable  records  in  the  database. 


5.  PROCEDURE  DLDXXXX < XXXX : XXXX_REC ;  VREFERENCE : 3UFF4 ; 
CODE:  typekey) :  The  Delete  Variable  Record  routine  removes  a 
record  from  the  database  in  the  file  indicated  by  the  four  letter 
code:  XXXX.  The  record  must  be  read  in  the  update  mode  before  it 
is  deleted. 

Database  Backup  Utilities 

It  has  been  proven  by  years  of  experience  that  any  given 
machine  will  sooner  or  later  break  down.  To  guard  against 
such  disasters,  a  system  of  backup  utility  programs  will  be 
employed  to  retrieve  the  database  information  and  store  the  data 
in  sequential  files  that  can  be  read  and  transformed  back  to  the 
database.  Each  of  the  five  main  modules  will  have  the 
responsibility  for  backing  up  and  restoring  the  database.  The 
files  each  module  is  responsible  for  is  depicted  in  figure  3-9. 
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FIGURE  3-9(1)  FACTMOD  BACKUP  FILES 
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FIGURE  3-9(2)  STDTMOD  BACKUP  FILES 
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FIGURE  3-9(3)  THESMOD  BACKUP  FILES 
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FIGURE  3-9(4)  MCRSMOD 
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FIGURE  3-9(5)  SEQUMOD  BACKUP  FILES 


Database  Algor i thms  Selection 

To  eliminate  the  need  for  sorting  and  to  decrease  the  search 


time  involved  with  large  list,  a  doubly  linked  list  will  be 
maintained  by  the  programs  for  each  master  file  associated  with 
the  module.  This  will  reduce  the  amount  of  database  accesses 
needed  by  maintaining  a  minimum  amount  of  information  in  a  linked 
list.  Since  the  lists  will  be  inserted  in  alphabetic  order,  no 
sorting  will  be  required,  so  the  insertion  of  an  item  will  take 
on  the  average  0(N/2)  number  of  record  compar r i sons ,  where  (N)  is 
the  number  of  records  in  the  list.  The  search  for  an  item  will 
take  the  same  amount  of  time.  The  linked  list  approach  also  allows 
us  to  dynamically  allocate  storage  for  the  records  which 
eliminates  the  need  to  maintain  a  large  unused  storage  area. 
However,  for  less  volatile  files,  such  as  the  Master  Section 
File,  a  simple  array  of  records  can  be  loaded  and  maintained  at 
the  beginning  of  the  interactive  session.  The  routines  needed  to 
maintain  and  access  these  lists  are  described  below  using  psuedo 
code . 

1.  ADD_XXXX (  XXXX: XXXX_PTR;  HEADER: XXXX_PTR) ; 

BEGIN 

If  the  HEADER  is  nil  then  create  a  new  header 
record 

else  get  the  next  record  after  the  header  record, 
while  the  search  pointer  is  not  nil  and 
the  input  node  is  >  searched  node  then  begin 
get  the  next  record 

end 

insert  the  new  pointer  in  the  list, 
end . 

2.  DEL_XXX  (  CTRL: typekey ;  VAR  HEADER: XXXX_PTR) ; 

BEGIN 

While  not  at  end  of  list  and  not  found  do 
get  next  record 
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end  do; 

if  found  then  remove  node 
END; 

3.  FIND_XXXX(  Name:  nametype;  CTRL : ctr ltype ;  LIST:  listtype) 
BEGIN 

while  no  match  (name  =  list. name)  do 
current. ptr  :=  cur ren t . ptr * .next 
if  found  then  Ctrl  :=  current. Ctrl 
else  Ctrl  :=  spaces. 

END; 

Inter  face  Design  Considerations 

The  four  main  features  of  a  "user-friendly"  interface  for 
the  AFIT/ENG  Database  System  are: 

1.  Allowing  the  user  to  navigate  through  the  control 
paths  of  the  interface,  following  the  structure  as  though 
traversing  a  tree. 

2.  Allowing  the  user  to  enter  input  data,  and  have 
the  user  select  data  to  avoid  user  input  errors.  Example: 
Selecting  a  student  from  a  list  of  students  instead  of  looking  up 
the  social  security  number  to  enter  as  a  key. 

3.  Informing  the  user  of  errors  in  as  much  detail  as 
possible  and  always  giving  the  user  a  way  to  recover. 

4.  The  aid  of  a  help  function  to  tell  the  user  what  the 
machine  is  expecting  as  input. 

5.  Avoid  putting  default  values  in  the  menu  to  prevent 
the  accidental  selection  of  an  option  such  as  "9"  (exit).  Initial 
tests  showed  that  when  response  was  slow,  users  would  hit  the 
return  key  to  elicit  a  response  and  inadvertently  exit  the 
program. 

The  method  of  integrating  these  features  are  through  the 
design  of  the  program  in  a  structured  form  to  allow  for  the  tree 
structure  to  be  implemented,  the  visual  design  of  the  human 


interfaces,  the  selection  of  phrases  that  would  be  familiar  to 
the  user,  and  the  design  of  the  help  displays. 

Visual  De s i g n  Considerations 

Since  the  "user-friendliness"  of  a  system  is  determined  by 
the  user  through  the  visual  displays  and  interfaces,  the  design 
of  the  screen  output  media  becomes  very  important.  The  main 
consideration  behind  the  desing  of  the  screen  frames  and  display 
formats  will  be  the  following  criteria: 

1:  The  displays  will  remain  consistant  from  one  portion 
of  the  database  to  another.  Student  and  faculty  information  will 
be  displayed  in  the  same  manner  as  will  the  course  sequences, 
degree  requirements,  and  educations  plans. 

2.  Items  selected  from  a  menu  will  remain  consistent 
thoughout  the  database,  using  numbers  to  select  a  particular 
function.  When  performing  adds,  updates,  deletes,  reviews,  and 
special  functions  within  a  frame,  the  number  1  will  be  used  to 
select  the  add,  number  2  to  select  the  update,  3  to  select  the 
delete,  the  number  4  to  select  the  review,  and  5  through  8  for 
special  functions.  The  number  9  will  be  used  to  exit  the  menu. 

3.  Each  screen  should  allow  the  user  to  abort  the 
function  and  recover  to  the  previous  menu.  The  information  such 
as  how  to  move  through  a  screen,  how  to  enter  data,  how  to  abort 
the  screen,  and  how  to  call  the  help  text  should  be  displayed  on 
the  frame  or  available  upon  pressing  the  Pf2  key. 

4.  The  title  of  the  screen  should  appear  at  the  top  of 
the  form  in  oversize  letters  in  reverse  video  or  bold  colors. 

The  use  of  bolding  should  be  limited  as  it  tends  to  clutter  the 


screen  and  this  type  of  graphics  is  not  compatable  with  many 


terminals.  Columns  of  data  such  as  the  kind  that  appear  on  the 
course  sequence  add,  update,  and  review  screens  can  be  displ*  'ed 
in  reverse  video  to  highlight  that  they  are  data  and  not  titles. 

Help  Level  Integration  and  Tutor ials 
There  are  three  kinds  of  users  to  any  system: 

1:  The  novice  is  a  new  user  of  the  system,  and  has 
little  or  no  experience  with  similar  systems.  This  user  requires  a 
great  deal  of  assistance  and  training. 

2:  The  casual  user  is  one  that  uses  the  system  three  or 
four  times  a  month  or  a  new  user  that's  had  experience  with  some 
similar  systems.  This  kind  of  user  needs  help  occasionally  but 
can  otherwise  use  the  system  effectively. 

3:  The  expert  user  is  a  person  who  is  very  familiar 
with  the  system  and  uses  it  on  a  day  to  day  basis.  Little  or  no 
help  is  required  for  this  type  of  user. 

The  use  of  the  database  system  will  assumed  to  be  on  a 
casual  level.  (2)  The  majority  of  work  will  come  at  the  end  and 
beginning  of  quarter  when  new  students  nre  added,  old  students 
are  archived,  classes  are  changed,  and  schedules  are  run.  During 
the  majority  of  the  quarter,  the  use  of  the  database  system  will 
be  directed  to  generating  management  information  and  running  of 
course  and  student  listings.  There  will  be  very  few  people 
categorized  as  expert  users.  For  this  reason,  a  menu  driven 
system  was  selected  instead  of  a  operation  and  operand  system. 

The  system  will  be  configured  to  accomodate  the  casual  user 
most  of  the  time.  The  novice  user  need  only  select  the  tutorials 
that  will  be  implemented  with  each  main  module  or  select  the  PF2 
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(help)  key  to  find  out  what  the  machine  is  expecting. 

Summary  Of  Design  Considerations 

Besides  the  enhancements  to  the  database  schema  and  the 
structure  charts  in  the  appendices,  the  following  represent  all 
of  the  design  considerations  presented  in  this  chapter. 

1.  The  entire  AFIT/ENG  Database  System  will  be  decomposed 
into  five  main  modules  or  programs.  The  programs  are  name  (1) 
FACTMOD,  (2)  STDTMOD,  (3)  MCRSMOD,  (4)  THESMOD,  (5)  SEQUMOD. 

Each  of  these  modules  will  have  update  responsibility  for 
different  parts  of  the  database. 

2.  Certain  routines  and  list  structures  should  be 
abstracted  into  pre-defined  operations.  The  AFITDB  TOTAL 
database  system  will  have  record  type  definitions  and  read, 
write,  update,  and  delete  routines  defined  on  them.  In 
addition,  a  linked  list  of  often  used  record  names  and  keys  will 
be  maintained  to  decrease  the  search  time  required  to  access  the 
TOTAL  database  system. 

3.  Each  master  file  will  have  at  the  very  least  a  set  of 
standard  functions  the  user  will  be  able  to  perform.  The  user 
should  be  able  to  add,  update,  delete,  and  review  records  with 
the  option  for  hardcopy. 

4.  To  accomodate  changes  in  the  size  of  the  AFIT 
organization,  the  database  should  have  the  ability  to  save 
records,  re-generate  the  database,  and  restore  the  database 
records . 

5.  The  requirements  stated  in  Appendix  E  state  the  need  for 
certain  reports.  These  include  but  are  not  limited  to:  (1) 
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Division  Faculty  Workload  Distribution  Document  (2)  Enrolled 
Student  listing  (3)  Couse  listing,  (4)  Student  locators  (5) 
Education  Plans  and,  (6)  Sequence  and  Degree  Requirements 
Listing . 

6.  To  insure  the  integrity  of  the  database,  the  data  must 
have  syntax  and  compatiblity  checks  performed  when  entering  data. 

7.  To  make  the  program  easy  to  maintain  and  modify,  an 
eight  layer  structure  of  software  should  be  used  (  figure  3-8)  . 

8.  A  library  of  standard  database  modules  should  be 
maintained  in  a  seperate  library  file  for  future  programmers  to 
use  in  creating  new  modules  or  enhancing  old  modules.  These 
routines  should  not  rely  on  any  global  variables  except  for  one. 
STATUS  should  be  defined  as  "STATUS :BUFF4"  through  out  any 
program  as  a  global  variable. 

9.  Each  of  the  main  modules  (figure  3-9)  should  have  the 
responsibilty  to  backup  and  restore  those  files  the  module  has 
update  priviledges  for.  This  option  should  be  password  protected 
and  should  be  done  on  a  weekly  basis. 

10.  When  programming  the  interface  to  the  user,  four  things 
should  be  considered:  (1)  Paths  through  the  system  should  be  well 
defined  and  should  not  change,  (2)  Rave  the  user  select  input 
instead  of  typing  it  in  to  improve  data  integrity,  (3)  Display 
detailed  error  messages,  (4)  Insure  the  PF2  key  works  in  all 
cases  to  provide  the  user  with  all  the  information  a  novice  would 
need . 

11.  The  visual  design  of  the  system  should  :  (1)  Limit  the 

amount  of  color  used  on  the  VT240  terminals,  (2)  Maintain 
standard  selection  terms  (i.e.  1=ADD ,  2=UPDATE. . . 9=EXIT) ,  (3) 


Each  screen  should  allow  the  user  to  exit  without  any  changes 
and,  (4)  Each  screen  should  have  a  title  at  the  top  of  the  screen 
in  double  letters. 

12.  The  system  should  be  designed  for  the  casual  user  and 
the  novice  should  have  access  to  all  of  the  help  and  tutorials 
needed  through  menu  selections  and  the  PF2  key. 

13.  The  lower  level  routines  should  be  designed  in  such  a 
manner  to  allow  maintenance  programmers  to  develop  a  command 
language  database  system  to  accomodate  the  expert  users  and  allow 
access  to  the  database  through  devices  that  are  not  compatible 
with  FMS . 


3-34 


IV.  IMPLEMENTATION  AND  TEST 

This  chapter  discusses  how  the  proposed  design  of  an 
AFIT/ENG  Faculty  and  Student  Database  System  was  implemented  on 
a  Digital  Equipment  Corporation  (DEC)  11/780  computer  using  a 
VMS  operating  system.  The  implementation  of  this  system  was 
affected  by  many  different  factors.  The  availability  of  software 
that  has  already  been  written  greatly  affected  the  design 
considerations  outlined  in  chapter  3.  The  implementation  and 
testing  of  the  system  presented  in  this  chapter  will  identify 
those  characteristic  of  the  system  that  deviate  from  the  original 
design . 

The  topics  discussed  in  this  chapter  include:  an  evaluation 
of  the  database  prototype,  the  configuration  of  the  host 
computer,  forms  Management  System  features  and  usage,  the  TOTAL 
database  interface  and  integration  problems,  the  development  of 
the  EDPLAN  program,  database  generation  techniques  and  problems, 
system  integration,  and  module  test  plans. 

Prototype  Evaluation 

During  the  final  weeks  of  the  design  phase  and  the  start  of 
the  implementation  phase,  15  students  were  ask  to  participate  in 
a  mock  database  session.  All  of  the  people  ask  to  participate  fit 
the  description  of  the  standard  user.  Each  individual  was  given 
a  task  to  perform  and  taught  how  to  logon  to  the  computer,  how  to 
start  the  database,  and  how  to  use  the  help  key(PF2).  The 
subjects  were  observed  to  see  if  they  could  accomplish  the  task 
without  the  use  of  manuals  or  assistance.  During  the  session,  the 
subjects  were  encouraged  to  critique  the  system. 
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Several  comments  were  common  to  most  of  the  users  and 
several  offered  improvements  to  the  system.  The  list  below  is  a 
sample  of  comments  that  were  common  to  over  half  of  those  tested. 

1.  There  was  a  lack  of  help  menus  and  tutorials  on  most  of 
the  systems,  but  some  were  very  good.  The  best  was  the  help  menu 
in  the  education  plan  module  which  used  a  secondary  frame  to 
display  more  information. 

2.  Abbreviations  were  unclear  and  should  be  avoided  when 
possible . 

3.  When  the  users  pressed  the  PF2  (Help  key)  they  expected 
to  see  examples  of  what  they  needed  to  enter. 

4.  Several  screens  did  not  allow  the  user  to  exit  without 
performing  some  action  that  caused  a  change.  There  should  be  a 
way  to  exit  each  function  and  screen. 

5.  The  add,  update,  and  review  functions  look  very  similar. 
At  times  the  user  forgot  what  mode  he/she  was  in. 

6.  The  default  option  in  a  menu  (9  =  exit)  caused  a  problem 
when  the  system  was  slow  to  respond.  The  user  would  tap  the 
return  key  and  completely  exit  the  system.  The  default  should  be 
taken  out  and  left  blank. 

7.  Menus  changed  from  when  the  user  originally  signed  on 
(edplans),  this  confused  the  user.  They  did  not  know  if  they 
were  in  the  correct  part  of  the  database  system.  The  menus 
should  remain  consistant. 

8.  There  were  two  types  of  scrolling  and  selection  of 
records.  One  method  had  the  user  scroll  a  list  by,  select  a 
record  and  then  enter  a  coded  number  that  appeared  beside  the 


record.  The  other  method  also  scrolled  the  items  by,  but  the 


user  selected  a  record  by  placing  an  "x"  beside  the  record  to  be 
selected.  The  majority  of  the  users  prefered  the  first  method 
because  the  placing  of  the  cursor  beside  the  location  took  longer 
than  it  did  to  just  enter  a  number. 

9.  The  faculty  module  had  the  beeper  turned  on  which  bother 
the  user.  The  beeper  served  no  purpose  other  than  to  embarris 
the  user. 

10.  When  upu'ting  course  sequences  and  edplans,  the 
updating  started  at  the  personal  data  part.  This  usually  does 
not  change  and  the  majority  of  those  tested  suggested  that  the 
position  of  the  cursor  be  placed  at  the  first  class  list  and 
allow  the  user  to  back  up  to  the  personal  data  if  need  be. 

Host  Computer  Configuration 

The  configuration  of  the  host  computer  shall  be  a  major 
concern  in  the  future  implementation  of  transfer  of  the  AFIT/ENG 
Faculty  and  Student  database  system  to  another  computer.  This 
section  of  chapter  4  will  deal  with  the  computer  set  up  and  the 
file  systems  needed  to  support  the  TOTAL  DBMS  and  AFIT  database. 

The  computer  used  in  this  thesis  development  was  the  ISL  VAX 
11/780  located  in  room  245  of  the  building  640  (AFIT  School  of 
Engineering).  The  system  contains  2.5  megabytes  of  main  memory, 
four  RK07  disk  drives,  8  to  10  terminals,  one  on  line  printer, 
and  one  laser  printer.  The  two  types  of  terminals  used  in  the 
implemention  were  the  VT250  and  the  VT100.  The  VT250  had  color 
capability  and  was  used  in  some  applications.  The  operating 
system  used  on  the  computer  was  version  4.2  of  the  VAX/VMS 


operating  system  upgraded  from  version  3.6  half  way  through  the 
implementation.  This  produced  several  errors  in  the  software 
because  the  version  2.0  of  the  TOTAL  DBMS  was  not  compatible  with 
the  new  operating  system.  The  version  of  the  TOTAL  Database 
System  was  upgraded  from  2.0  to  3.5.  The  VMS  operating  system 
employed  demand  paging  system  using  a  fixed  size  of  512k  bytes 
per  page. 

The  TOTAL  DBMS  was  maintained  and  run  from  the  directory 
[AFITDB. TOTAL]  and  maintained  under  the  disk  pack  identified  by 
DUA0:.  To  access  the  TOTAL  database  system  commands,  the  user 
must  logon  under  the  user  id  of  "AFITDB".  Once  on  the  system,  the 
following  VMS  instruction  was  needed  to  put  the  user  inside  the 
directory:  "SET  DEF  DUA0 :[ AFITDB . TOTAL] " .  The  TOTAL  DBMS  could 
then  be  generated,  submitted  and  started  execution.  All  of  the 
datafiles  and  TOTAL  utility  programs  were  kept  under  the  same 
directory  name  for  ease  of  access  and  maintainability.  To  Back 
the  database  files,  the  entire  data  files  were  copied  to  an 
identical  directory  protected  by  the  system  identification  on  the 
disk  pack  DUA0 :  To  restore  the  database,  the  files  were  just 
copied  back  to  the  original  disk  pack  under  a  user  id  with  system 
pr  i  v i ledges . 

The  application  software  (i.e.  FACTMOD,  SEQUMOD, . . .etc )  were 
maintained  on  the  same  disk  pack  as  the  TOTAL  DBMS  but  under  a 
seperate  directory  called  "AFITDB".  To  compile  and  link  a 
program  with  the  TOTAL  database  system,  the  following  VMS 
commands  must  be  used: 

$  PAS/ NOWARN  pcogr amname . PAS 


ja^rKssmsanMMBMirB^  aBBBa»Mwe  msssn  smm 


! 

! 

$LINK  prog r amname , DUA0 : [ AFITDB . TOTAL] NATDATBAS , NATBUF 
|  The  term  "programname"  is  the  file  name  given  to  location  of  the 

source  program.  To  then  execute  the  program,  the  instruction 
$  RUN  programname  is  used.  This  assumes  that  the  programmer  has 
correctly  signed  on  and  accessed  the  database  system  properly 
(see  appendix  F  for  examples). 

Forms  Management  System  Uti li zation 

Each  module  (i.e  STDTMOD,  FACTMOD  ...etc)  has  associated 
with  it  the  FMS  library  of  the  same  name  that  containing  all  of 
the  menus  and  screens  the  module  needs  to  use  for  an  interactive 
session.  Therefore,  the  frames  library  associated  with  the 
STDTMOD. EXE  module  would  be  maintained  as  STDTMOD. FLB.  The 
screens  used  are  described  in  Appendix  E  and  follow  certain 

z-  conventions. 

!• 

The  conventions  or  standards  were  developed  using  the 
prototype  as  a  means  of  testing  the  reaction  of  different 
techniques  on  perspective  users.  The  standards  developed 
from  the  use  of  the  prototype  are: 

1.  Different  transactions  were  selected  using  a  number 
instead  of  a  alphabetic  symbol  such  as  ADD,  or  DEL.  The  number  1 
was  always  used  to  add  records,  2  is  always  used  to  update  and 
so  on* 

2.  The  number  9  is  always  used  to  exit  to  the  previous 
menu  or  system.  This  also  limits  the  number  of  selections  on  a 
screen  by  not  allowing  room  for  anymore  selection  on  the  screen. 


3.  Auto  tabbing  was  not  used  as  it  is  often  confusing  to 
the  casual  user  and  promoted  mistakes  in  entering  data.  When 
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entering  text  information,  data  contained  in  one  field  would 
spill  into  another  field  by  mistake. 

4.  The  use  of  scrolled  areas  to  select  names  of  students 
and  faculty,  book  titles,  sequence  titles,  degree  names,  and 
section  names  reduced  the  need  to  memorize  keys  such  as  social 
security  numbers,  sequence  numbers,  and  lengthy  book  titles. 

5.  The  use  of  bold  areas,  reverse  video,  double  wide 
letters,  and  boxes  were  kept  to  a  minimum  because  of  their 
incompatibility  with  other  terminals  that  were  not  VT52,  VT100,  and 
VT240  used  in  the  development  of  the  system. 

6.  Each  screen  employed  a  method  to  exit  the  current 
operation  without  change.  For  menus  it  was  accomplished  using 
the  number  9,  and  for  other  screens,  hitting  return  on  the  first 
field  caused  the  program  to  exit  to  the  previous  operation. 

7.  The  method  used  to  move  around  screen  is  by  use  of  the 
'TAB'  and  'Backspace'  or  'CTRL  H'  keys.  The  tab  advances  the 
cursor  while  the  Backspace  or  'CTRL  H'  key  moved  the  cursor  back 
one  field.  The  'Delete'  key  removed  a  character  up  until  the 
beginning  of  the  field.  Furthor  specifics  can  be  found  in  the 
VAX-11  Software  Reference  Manual  (10). 

3.  Often,  more  than  one  transaction  of  the  same  type  would 
need  to  be  accomplished  such  as  updates  to  the  students  edplans. 
Usually,  a  secretary  would  bring  several  students  records  to 
update  at  one  time.  This  would  require  the  screen  to  be 
displayed  to  update  students  records  until  it  was  cancelled  by 
one  of  the  methods  mentioned  before. 

9.  The  FMS  program  employs  two  basic  types  of  GET  calls 


that  retreive  information  from  the  screen.  The  first  is 
FDV$GETAL  which  retrieves  the  entire  screen  into  on  large  buffer 
where  the  program  must  retreive  the  information.  This  allows  the 
use  of  the  'Backspace'  key  to  move  to  the  previous  field  but  the 
program  has  no  control  of  the  operation  until  the  FMS  driver 
releases  the  information.  The  other  is  the  FDV$GET  which 
retreives  one  item  at  a  time  but  does  not  allow  the  user  to  back 
up  to  the  previous  item  but  does  allow  for  edit  checks  on  the 
items  as  they  are  entered.  The  latter  of  the  two  was  used 
because  it  allowed  for  edit  checks  and  the  data  item  'TERMINATOR' 
was  checked  for  the  'Backspace'  key  to  allow  the  user  the  ability 
to  go  back  to  the  previous  field. 

Education  Plan  Progr arm  Developement 

The  requirements  for  the  EDPLAN  program  were  essentially 
defined  by  engineer  Robert  Ewing  in  his  development  of  the  EDPLAN 
prototype.  The  main  requirements  for  the  program  were  to  1) 
enable  new  students  to  enter  their  personal  information  and  an 
initial  education  plan  and  sequence  declaration,  2)  allow  the 
students  to  update  the  edplans,  3)  allow  students  and  faculty  to 
review  and  print  the  education  plans,  and  4)  generate  a  file  that 
could  be  passed  to  the  scheduling  office  that  would  allow  them  to 
schedule  classes. 

The  first  step  in  creating  the  program  was  to  copy  the  files 
TYPE. PAS  and  UTIL. PAS  from  the  DUA1 : [ PANGMAN]  directory  into  a 
file  called  EDPLAN. PAS.  The  files  TYPE. PAS  and  UTIL. PAS  hold 
the  standard  type  declarations,  standard  database  routines,  and 
link  list  routines  as  described  in  chapter  3.  A  forms  library 
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all  syntax  errors  and  as  many  logic  errors  as  possible  had  been 
detected  so  the  code  contained  in  EDPLAN . PAS  was  in  working 
condi tion . 


A  main  routine  was  created  and  performed  the  following 


steps : 

1.  Initialized  the  FMS  driver  and  opened  the  form  library. 

2.  Signed  on  to  the  database  system.  If  the  database  system 
was  not  operational  then  the  program  exited. 

3.  Built  the  linked  list  for  the  faculty,  students,  and  an 
array  of  the  class  section. 

4.  Set  up  a  WHILE  loop  to  detect  the  type  of  transaction  the 
user  wanted: 

a.  Add  an  Education  Plan; 

b.  Update  an  Education  Plan; 

c.  Delete  an  Education  Plan; 

d.  Review  an  Education  Plan; 

e.  List  Students  in  a  Section; 

£.  Print  an  Education  Plan  for  a  Student; 

g.  Print  Education  Plans  for  a  Section; 

h.  Generate  the  registration  summary  file; 

i.  or  Exit  the  Pogram. 

To  test  the  calls  to  the  various  routines,  stubs  were  put 
in  the  place  of  the  actual  routines  and  the  software  was  tested  to 
insure  it  signed  on  to  the  database  system,  initialized  the  FMS 


driver,  and  made  correct  calls  to  the  stubs  when  ever  a 


<1 

f. 


transaction  was  selected.  The  program  then  tested  to  see  if  it 
signed  off  of  the  database. 

The  routines  needed  to  add  the  education  plan  and  basic 
student  information  were  created  first  and  tested.  It  was 
important  to  insure  this  worked  first  for  several  reasons.  The 
first  reason  is  that  most  of  the  other  routines  read  information 
from  the  files.  The  update,  delete,  and  review  routines  would  use 
several  of  the  functions  and  procedures  developed  in  the  add 
procedure.  Since  most  of  the  procedures  to  read  and  write  to  the 
database  had  been  developed  and  tested  (Appendix  I),  the  majority 
of  the  programming  effort  was  concentrated  on  providing  a  "user- 
friendly"  interface  to  the  program  and  providing  as  much  error 
checking  as  possible.  Help  messages  and  menus  were  programmed  in 
to  provide  information  to  the  novice  user. 

The  next  set  of  routines  developed  were  the  update  routines. 
The  only  difference  between  the  add  and  the  update  routines  was 
the  need  to  read  a  students  master  and  course  records.  This 
involved  selecting  a  student  from  the  database  system.  Since  few 
individuals  would  have  access  to  the  social  security  numbers,  it 
was  decided  to  develop  a  way  to  access  a  record  using  the  last 
name.  If  more  than  one  student  had  the  same  last  name,  a  list  of 
these  names  would  appear  and  allow  a  selection  to  be  made.  A 
combination  of  the  linked  list  routines,  and  the  FMS  scrolling 
ability  aided  in  this  design. 

With  the  above  routines  completed  and  tested,  the  review  and 
list  students  routines  were  completed  using  a  combination  of  the 
add,  and  update  routines.  These  were  completed  and  tested  in  a 


4-10 


matter  of  hours  because  all  of  the  routines  called  had  been 


developed  and  tested  earlier.  The  last  routines  completed  were  the 
printing  routines  which  basically  followed  the  review  routines  in 
their  format.  Using  this  program  as  a  basis,  other  pieces  of 
software  can  be  developed  in  minimal  time  if  some  basic  rules 
layed  down  by  this  thesis  as  followed. 

Edplan  Program  Un i que  Routine  .Descr i ptions 

The  following  descriptions  are  of  the  routines  developed  for 
the  EDPLAN  program  only.  However,  using  these  routines  are 
guides  will  aid  in  the  development  of  other  programs. 

1.  PROCEDURE  FINDSECTION (VAR  FIND:  LINK_PTR;  SEARCHSECT : BUFF8 ) ; 
This  routine  finds  the  first  occurance  of  a  student  who 

belongs  to  a  specific  section  passed  via  the  SEARCHSECT 
parameter.  The  starting  location  is  passed  in  the  FIND  parameter 
and  the  location  is  passed  back  through  the  same  pointer.  The 
routine  was  designed  to  be  called  until  the  entire  list  of 
student  or  faculty  members  had  been  exhausted. 

2.  PROCEDURE  DISPLAY_NAME ( VAR  NAME : BUFF28 ;  VAR  CTRL : BUFF9 ; 

CURR: LINK_ARRAY) ; 

This  routine  was  designed  to  find  a  student's  or  faculty 
member's  social  security  number  given  his  last  name  or  a  subset 
of  his  last  name.  This  is  accomplished  by  searching  the  linked 
list  of  students  or  faculty  for  all  the  names  that  match  the 
input  name  passed  by  the  parameter  NAME,  when  this  routine  is 
called,  if  more  than  one  name  is  found  to  match,  then  all  of 
the  matching  names  are  passed  through  the  parameter  CURR.  Using 


the  FMS  scrolling  feature,  the  names  are  presented  to  the  user 
and  the  user  can  either  make  a  selection  or  abandon  the  screen,  in 
which  case,  a  blank  social  security  number  is  returned.  The 
blank  social  security  number  indicates  no  names  were  found. 

3.  PROCEDURE  GETVCQR  (VAR  VCQR:  VCQR_ARRAY ;  CTRL:  BUFF9) ; 

This  module  reads  the  courses  a  student  has  entered  into  his 
education  plan  into  an  array  of  variable  course  quarter  records, 
allowing  up  to  120  records.  It  formats  the  records  into  the  array  so  the 
appear  in  the  proper  column  when  displayed  by  FMS. 

4.  PROCEDURE  FILLEDPLAN  ( STDT : STDT_REC ;  VCQR : VCQR_ARRAY) ; 

This  procedure  fills  the  FMS  screen  ' EDPLAN1 '  with  the 

students  name,  rank,  social  security  number,  box  number,  primary 
afsc,  education  code  and  courses. 

5.  PROCEDURE  GETADVISOR (  VAR  NAME : BUFF 2 8 ;  VAR  CTRL : BUFF9 ) ; 

The  procedure  GETADVISOR  retrieves  a  faculty  members  social 
security  number  and  master  record  by  calling  the  procedure 
FINDNAME  for  all  occurences  of  instructors  with  the  same  last 
name.  If  only  one  is  found  then  the  record  is  read  and  the 
information  passed  back,  if  more  than  one  is  found  then  the 
procedure  DISPLAY_NAME  is  called  to  select  one  of  them. 

6.  PROCEDURE  GETSTUDENT (  VAR  NAME : BUFF28 ;  VAR  CTRL : BUFF9) ; 

This  procedure  performs  the  same  function  as  GETADVISOR 
except  it  is  done  for  students  names. 

7.  PROCEDURE  UPTSEQ(VCQR:  VCQR_ARRAY) ; 

This  routine  deletes  and  re-creates  the  associated  course 
files  for  the  student.  The  array  is  sorted  based  upon  the  year 
and  quarter  the  course  will  be  taken,  and  then  the  copy  of  the 
courses  in  the  CRSE_ARRAY  are  displayed  and  updated  to  reflect  if 
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the  courses  are  SEQA,  SEQB,  MATH,  THES,  or  WAIV  type  courses. 

8.  PROCEDURE  ADDPLAN ; 

This  procedure  initially  adds  a  students  personal  data  and 
6basic  edplan  into  the  system.  The  procedure  UPTSEQ  is  called  to 
write  the  course  information  to  the  database. 

9.  PROCEDURE  UPTEDPLAN; 

This  procedure  updates  a  students  education  plan  by  reading 
in  his/her  previous  plan  and  displaying  this  to  the  user.  Once 
the  plan  is  read  in,  the  courses  are  sorted  based  on  the  year 
and  quarter  and  written  back  to  the  database.  These  courses  are 
then  copied  into  an  array  of  records  of  type  CRSE_ARRAY  where  the 
user  defines  them  as  SEQA,  SEQB,  THES,  MATH,  or  WAIV  courses. 

This  routine  allows  the  programmer  to  add  edit  checks  while  the 
courses  are  read  in  from  the  screen  so  that  at  the  end  of  the 
session,  all  course  entered  are  valid.  The  student  is  not 
deleted  from  the  database  and  the  course  taken  are  archived  in 
the  Registrars  office. 

10.  PROCEDURE  DELEDPLAN; 

This  module  deletes  a  students  education  plan  from  the  data 
base  but  does  not  delete  the  student  information  from  the  STDT 
master  file.  The  student  is  selected  using  the  GETSTUDENT 
routine  and  the  edplan  is  displayed  to  the  user  to  insure  that 
this  is  the  plan  they  wish  to  delete.  Only  after  the  user  has 
affirmed  the  decision  will  the  plan  be  deleted. 

11.  PROCEDURE  REVEDPLAN; 

This  routine  functions  much  in  the  same  way  that  the 
UPTEDPLAN  routine  does  except  it  does  not  allow  the  user  to 


udpate  any  information. 

12.  PROCEDURE  LISTSTDT; 

This  routine  lists  all  of  the  students  who  belong  to  a 
specific  section  by  searching  the  linked  lists  and  passing  the 
selected  names  to  the  DISPLAY_NAME  routine. 

13.  PROCEDURE  PRINTCOURSE (COURSE : BUFF8 ;  VAR  CUM,QTR:  INTEGER); 

The  PRINTCOURSE  subroutine  accepts  as  parameters  the  8 
character  course  code  and  the  cumulative  and  quarterly  hour 
totals.  The  procedure  reads  the  master  course  file  to  obtain  the 
title  of  the  course  and  its  credit  hours,  and  then  converts  the 
number  to  an  integer  and  adds  them  to  the  totals.  The  procedure 
then  writes  the  course  description  to  the  file  "RECORDS". 

14.  PROCEDURE  PRINTSEQ ( STDT :  STDT_REC;  SECTION:BUFF8) ; 

This  procedure  produces  the  second  page  of  the  education 
plan  report  by  printing  the  course  sequence  declaration  as 
described  by  the  student  or  faculty  member. 

15.  PROCEDURE  PRINTHEAD; 

This  procedure  prints  the  header  for  each  quarter  of  the 
education  plan  report  or  the  header  for  each  sequence. 

16.  PROCEDURE  PRINTTAIL (VAR  CUM, QTR:  INTEGER); 

This  procedure  prints  the  totals  for  each  quarter  and  the 
cumulative  totals. 

17.  PROCEDURE  PRINTEDPLAN ( 3SAN :  BUFF9  ;  FLAG:  BOOLEAN); 

This  procedure  controls  the  printing  of  the  first  page  of 
the  education  plan.  It  prints  the  course  a  student  is  taking  by 
the  quarter.  It  then  reads  the  VCQR  file,  formats  the  output  and 
prints  the  information.  If  a  flag  is  sent  to  the  routine  as 


TRUE,  then  the  second  page  of  the  report  is  also  printed  which 
contains  the  sequence  declarations. 

18.  PROCEDURE  PTREDPLAN; 

The  procedure  reads  in  the  student's  name  whose  edplan  is 
requested.  If  the  edplan  is  found,  the  user  must  enter  whether  a 
request  for  the  second  page  is  needed.  The  PRINTEDPLAN  routine 
is  then  called. 

19.  PROCEDURE  SECEDPLAN; 

This  procedure  reads  the  section  code  from  the  user  and 
gathers  all  of  the  students  who  belong  in  that  section  from  the 
linked  list.  The  names  are  then  sent  one  by  one  to  the  procedure 
PRINTEDPLAN.  The  file  'RECORDS'  is  then  printed  and  deleted. 
Other  Modules  Under  Development 

In  order  to  accomplish  many  of  the  tasks  required  in  the 
EDPLAN  program,  many  other  forms  of  data  were  required  in  the 
database  system.  For  instance,  faculty  records,  section 
description,  courses  offered,  department  information,  and  several 
other  items  needed  to  be  in  the  database  in  order  for  the 
variable  records  to  be  added.  A  section  advisor  record  ( FADV) 
could  not  be  added  if  a  faculty  member  with  the  specified  social 
security  number  did  not  exist  and  the  master  section  record  did 
not  exist.  The  basic  maintenance  modules  for  all  of  the  master 
files  were  constructed  at  one  time  by  the  EENG  646  database 
class.  A  brief  description  of  the  modules  constructed  using  the 
above  programming  techniques  and  some  of  those  gathered  from  the 
WINTER  1985  EENG  646  class  are  described  below. 

1)  FACTMOD . PAS :  This  program  allowed  the  addition,  update, 
deletion  and  review  of  all  of  the  faculty  master  records. 
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2)  SEQMOD . PAS :  This  module  allows  members  to  describe  course 
sequences  so  students  will  be  able  to  check  their  education  plans 
to  insure  they  have  enough  credits  in  the  right  courses  to 
graduate.  Course  sequences  can  be  added,  updated,  deleted, 
reviewed,  and  students  can  check  their  education  plans  against 
them . 

3)  BOOK. PAS:  This  file  maintains  the  text  book  titles, 
order  information,  and  re-order  information.  Currently,  book 
information  can  be  added,  updated,  deleted  and  reviewed. 

System  Integration 

The  integration  of  the  system  was  simple  and  very  flexible. 
The  design  of  the  system  allowed  the  Data  Base  Admin i stator 
several  options.  Each  module  (i.e  STDTMOD ,  FACTMOD. . .etc)  could 
be  called  individualy,  allowing  access  to  certain  users  by 
using  the  system  priviledge  codes.  Several  of  the  programs  could 
be  combined  into  a  large  program  with  a  small  main  routine  to 
drive  them  both  .Or,  a  .COM  {  command  file)  could  be  used  to 
control  the  calls  to  each  of  the  modules. 

The  latter  of  the  options  was  chosen  because  it  allowed  the 
mixing  of  modules  with  out  re-compiling  the  programs  and  linking 
the  data  base  system  with  the  object  modules.  This  also  allowed 
the  DBMS  Manager  to  re-start  the  TOTAL  DBMS  system  by  use  of  a 
filename.COM  file  if  the  first  call  to  the  TOTAL  DBMS  failed  to 
sign  on.  This  solution  relies  on  the  version  of  VMS  currently 
on  the  machine  and  could  pose  a  problem  in  the  future  if  a 
different  operating  system  was  used.  A  better  solution  would  be 
to  have  a  program  which  called  the  modules  as  external  references 
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much,  using  the  programs  as  subroutines. 
Test  Plan 


A  formal  test  plan  was  used  to  test  the  lower  level  database 
modules  in  the  beginnig  to  insure  they  worked  properly  with  the 
database.  Several  conditions  had  to  be  met  in  order  to  insure 
their  validity: 

1.  Each  module  had  to  work  with  an  empty  database. 

2.  Each  module  had  to  return  a  valid  status  code. 

J.  Each  module  was  required  to  return  or  send  valid  data 
and  to  detect  data  sent  in  other  than  character  form. 

4.  The  linked  list  routines  must  work  with  an  empty  list  of 
names,  and  up  to  the  maximum  number  of  names  allowed  in  the 
database.  Some  special  cases  occured  with  one  and  two  names  in 
the  system,  but  these  were  detected  and  handled. 

The  validation  of  the  standard  routines  was  conducted  very 
early  in  the  design  phase.  The  modules  were  working  at  the  time 
when  the  overall  system  was  being  coded.  They  were  used  as 
extensions  to  the  PASCAL  language  and  not  as  independent  modules. 
The  test  plans  followed  by  this  thesis  are  identical  to  those 
developed  by  Pangman  (2)  and  Bailor  (7)  in  their  theses 
on  the  same  subject.  The  test  plans  can  be  found  in  Appendix  I. 
Summary 

This  chapter  developed  the  details  of  coding  and 
implementing  a  portion  of  the  AFIT/ENG  Database  Design  on  the  VAX 
11/780  and  the  TOTAL  DBMS.  The  education  plan  was  chosen  because 
it  was  under  prototype  development  by  the  department,  and  has  a 
great  potential  for  decreasing  the  workload  on  the  faculty.  The 
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actual  configuration  of  the  VAX  11/780  was  described  to  aid  in 
future  development  of  the  AFIT/EN  Database  and  in  the 
configuration  of  the  system  to  facilitate  transfer  to  another 
computer  when  the  sytem  becomes  fully  operational.  The  EDPLAN 
program  was  examined  in  detail  to  provide  future  programmers  and 
analyst  an  insight  into  the  program  development  methodology  and 
design.  It  is  hoped  that  any  future  attempts  will  follow  the 
structured  programming  of  the  EDPLAN  module  during  modifications 
of  the  code,  and  on  any  programs  currently  under  developement . 
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Chapter  5 

V.  Conclusions  and  Recommendations 

Introduction 

This  chapter  presents  the  conclusions,  problem  areas,  and 
recommendations  derived  from  the  results  achieved  by  this  study. 
Thoughout  the  course  of  this  effort  the  human  computer  interface 
and  user  requirements  were  highlighted  as  well  as  the  Software 
Development  Life  Cycle.  From  the  beginning,  the  project 
proceeded  upon  the  assumption  that  the  software  produced  by  this 
project  would  be  used  by  the  AFIT  Shool  of  Engineering 
Department  Electrical  and  Computer  Engineering,  if  not  the  entire 
school,  as  a  protoype  for  future  development.  The  main  effort 
was  to  produce  a  standard  set  of  software  products  that  adhered 
to  the  practices  of  good  software  engineering. 

Conclusion 

The  intial  part  of  this  effort  was  to  examine  the 
requirements  of  the  AFIT/ENG  Department  and  compare  these 
requirements  with  past  theses  efforts  by  Pangman  (2),  Allred(12), 
and  Ricks (13).  Some  of  the  requirements  had  changed  and  are 
still  changing.  Information  such  as  faculty  personal  data, 
course  names,  privacy  act  regulations,  sequence  requirments, 
degree  requirements,  and  department  changes  will  greatly  effect 
the  database  structure  and  the  associated  computer  programs. 

The  next  step  was  to  examine  the  functional  requirements  of 
the  database  and  the  user-interface  requirements.  The  functional 
part  of  the  database  described  what  data  was  to  be  stored,  how 
the  data  was  stored,  how  the  software  was  to  interact,  the 
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overall  structure,  the  reports  to  be  generated,  and  the  purpose 
of  the  system.  At  this  point  it  was  decided  to  define  some 
standard  functions  that  would  act  as  auxiliary  operations  to  the 
Pascal  language.  These  functions  and  procedures  would  be  available  to 
all  of  the  program  segments  and  modules. 

The  human-interface  requirements  took  into  account  how  the 
information  was  presented  to  the  user,  the  skill  level  of  the 
average  user,  average  age,  and  access  priviledge.  Using  these 
critera  the  characteristics  of  a  standard  user  were  developed  by 
which  the  interface  systems  could  be  taylored.  A  prototype  of  the 
education  plan  program  ( EDPLAN)  was  developed  and  tested  on  the 
incoming  class  of  students  where.  They  were  required  to  enter 
their  education  plan  on  the  system.  The  students  were  then 
interviewed  to  find  their  likes,  dislikes,  how  long  it  took  them 
to  learn  to  use  the  system,  and  how  "user-friendly"  they  thought 
it  was.  Using  the  feedback  from  the  prototype  system,  a  real 
education  program  was  developed  during  the  implementation  stage 
of  the  Software  Development  Life  Cycle. 

Having  defined  the  requirments  for  the  system,  the  next  step 
was  to  perform  a  preliminary  design  of  the  AFIT/ENG  Database 
System.  The  database  schema,  as  defined  by  Pangman  (2)  and  as 
modified  by  engineer  Robert  Ewing,  was  examined  for  relationships 
in  the  structure  that  were  intended  to  be  mapped  into  some  type  of 
query.  These  relationships  were  translated  into  further 
refinements  of  the  requiements.  The  method  for  development  chosen 
was  a  combination  of  top-down  and  bottom-up  design.  The  overall 
picture  was  depicted  in  structure  charts  while  the  common 
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routines  were  completely  developed  and  tested.  This  provides  a 
better  foundation  for  development  and  use  as  tools  for  future 
modifications.  The  requirements  for  the  system  were  well  defined 
and  mapped  almost  in  a  one-to-one  correspondence  into  a  design  of 
the  system. 

The  detailed  design  of  the  system  was  a  refinement  process 
from  the  preliminary  design  phase.  There  wasn't  an  exact  point 
in  the  process  where  the  preliminary  design  ended  and  the 
detailed  design  began.  It  was  more  of  a  smooth  transition  or 
evolution  of  software.  Because  of  the  complexity  of  the  design, 
layers  of  software  were  developed  following  the  stategy  of  the 
ISO  network  software.  Each  layer  was  developed  to  perform 
specific  tasks  at  specific  levels.  Using  dummy  procedures  as 
stubs,  each  layer  was  developed  seperately  from  the  others.  This 
provided  a  front  end  processor  to  the  TOTAL  DBMS.  The  detailed 
design  phase  also  involved  defining  the  help  level  descriptions 
and  tutorial  screens  which  are  important  to  the  type  of  user 
described  in  the  early  phases  of  the  development. 

The  next  phase  on  the  Software  Development  Life  Cycle  was 
the  implementation  phase  or  the  coding  phase.  This  phase 
involved  taking  the  detailed  design  and  putting  it  into  a 
computer  language  (Pascal  and  EMS) .  Much  of  the  software  which 
was  required  to  enter  data  into  the  database  was  developed  from 
the  EENG  646  DATABASE  SYSTEM  class  and  integrated  by  engineer 
Robert  Ewing.  These  modules  were  inspected  and  changed  to  fit 
the  design  as  described  by  this  thesis.  Additional  software  was 
developed  to  prove  the  design  to  be  a  solid  one.  User  comments 
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were  used  thoughout  the  implementation  phase  to  fine  tune  the 
system  to  the  needs  and  cognitive  styles  of  the  users.  The 
EDPLAN  program  was  developed  to  provide  an  example  of  the 
validity  of  the  design  and  to  stand  as  an  example  to  guide  the 
future  software  developments  and  modifications. 

Using  the  standard  database  routines  developed  in  this 
project,  the  availability  of  additional  software  from  the  EENG 
646  class,  and  the  use  of  the  FMS  (Forms  Management  System) 
caused  the  overall  development  of  the  system  to  proceeded  very 
smoothly.  The  maintenance  and  any  future  developments  should 
benefit  from  the  extensive  research  provide  by  this  and  previous 
efforts.  All  software  developed  from  this  project  is  kept  in  the 
Information  Sciences  Laboratory  as  version  2.2  of  the  AFIT/ENG 
Faculty  and  Student  Database  Management  System. 

Problems  Encountered 

The  most  prevelent  problem  in  the  beginning  was  the 
learning  curve  required  to  use  the  TOTAL  DBMS.  The  description 
of  the  schema,  signing  on  to  the  database  system,  declaring 
external  procedures,  and  the  complex  calling  routines  required  to 
access  the  TOTAL  DBMS  were  the  main  problems.  This  was 
addressed  by  putting  the  emphasis  on  the  thesis  in  developing 
routines  that  all  future  programmers  could  use  to  perform  these 
functions  in  an  easy  and  timely  manner. 

The  worst  problem  was  caused  when  the  operating  system  was 
changed  from  VMS  version  3.6  to  VMS  verison  4.2.  This  changed 
the  way  TOTAL  interfaced  with  the  operating  systems  mail  programs 
the  device  definitions,  and  the  logon  commands  required  to  run 


the  software.  The  version  of  TOTAL  currently  running  (2.2)  is 
the  same  version  that  runs  on  the  PDP-11  computer.  A  run  time 
simulation  program  is  used  to  run  the  PDP-11  code  on  the  VAX 
11/780.  This  software  was  also  required  to  be  updated  when  the 
operating  system  was  changed. 

The  other  problem  associated  with  the  change  in  operating 
systems  was  the  change  in  the  Pascal  compile  and  the  FMS 
definition  program.  The  new  operating  system  will  not  allow 
strings  of  different  sizes  to  be  assigned.  Before,  trunction  was 
expected  and  blanks  were  padded  at  the  end  of  the  sending  field. 

A  long  recieving  field  would  flag  a  Pascal  compile  error.  The 
new  compiler  would  not  flag  an  error  if  the  sending  field  was  to 
large  but  the  new  operating  system  would  issue  an  error  message 
and  abort  the  program  upon  executing  the  assignment  statement. 

The  software  was  changed  so  all  receiving  and  sending  fields  on 
assignments  statements  were  of  the  same  length.  The  new  FMS 
driver  program  was  compiled  using  the  new  version  of  the  Pascal 
compiler  using  the  following  format: 

$ P ASCAL/ENVI RONMENT  FDVDEF . 

Recommendations 

The  modular  approach  to  the  design  of  this  system  has 
evolved  over  several  iterations  of  the  requirements  and 
preliminary  design  phases.  It  was  the  intention  from  the 
beginning  that  the  maintenance  phase  of  the  Software  Life  Cycle 
would  contribute  much  to  the  capabilities  of  the  AFIT/ENG 
Database  System.  Future  work  should  concentrate  initially  on  the 
basic  maintenance  software  that  safeguards  the  data  integrity  and 


provides  a  "user  friendly"  interface  to  the  system.  The  first 
large  effort  that  should  be  put  in  to  this  database  is  the  entry 
of  data  on  to  the  database  is  the  faculty  information,  thesis 
titles  and  authors,  sequence  and  degree  requirments,  and  complete 
scheduling  information. 

Currently,  once  education  plans  or  grades  are  entered  into 
the  database,  they  are  transfered  by  tape  or  manually  to  the 
admissions  office  for  input  into  their  system.  A  set  of 
standards  and  methods  should  be  negotiated  between  the  two 
parties  to  accomplish  this  task  automatically.  This  would  also 
involve  forming  a  set  of  rules  and  standards  between  the  School 
of  Logistics,  School  of  Engineering  and  School  of  Civil 
Engineering.  The  main  objective  of  this  database  is  to  reduce 
the  workload  humans  have  to  perform  and  allow  faculty  to 
concentrate  on  academics  instead  of  administrative  duties. 

Another  recommendation  is  to  phase  in  the  ability  to  produce 
the  Graduate  Credit  Record  using  the  database  system.  A  simple 
formula  will  be  used  to  produce  the  credit  record  which 
calculates  the  grades  by  taking  thesis  courses  and  the  highest 
grades  from  all  graduate  level  course  and  calculating  the  grade 
point  average.  The  user  will  be  allowed  to  change  these 
decisions  by  tagging  and  untagging  specific  course  and  viewing 
the  change  in  credit  hours  and  grade  point  average  in  a  real  time 
environment.  Examples  of  this  screen  can  be  seen  in  Appendix  E. 

The  department  heads  should  draft  a  formal  letter  of 
responsibilities  for  the  database.  Issues  such  as  who  enters 
course  grades,  education  plan  changes,  sequence  requi rements , and 


has  access  to  privacy  act  information  should  be  addressed  before 
the  database  is  totally  integrated  in  the  School  of  Engineering. 
Some  these  problems  solved  if  a  driver  could  be  found  for  the 
Burroughs  terminals  that  would  allow  the  faculty  members  to  have 
access  to  the  database  from  their  office.  Currently,  the 
Burroughs  terminals  cannot  recognize  the  FMS  graphics  signals. 
Finding  a  VT100  simulator  for  these  systems  would  work,  or 
changing  the  FDVDEF.PAS  program  that  interacts  with  FMS  would 
also  be  a  solution. 

The  TOTAL  DBMS  system  currently  operates  in  a  secondary  mode 
to  the  VMS  operating  system.  It  must  go  through  a  PDP-11 
simulator  in  order  to  operate  a  16-bit  system  in  a  32-bit 
addressing  environment.  A  study  should  be  conducted  to  the 
possibility  of  converting  the  current  TOTAL  DBMS  to  a  version 
that  operates  under  the  VMS  4.2  operating  system  without  an 
emulatotr.  There  currently  exist  a  database  called  ULTRA  (17) 
that  would  satisfy  this  need.  The  ULTRA  Database  Management 
System  is  compatible  to  TOTAL  and  provides  a  relational  database 
front-end  processor.  This  would  by  all  indications  improve  the 
performance  of  the  database  by  a  considerable  margin  and  add  new 
capabilities  to  the  system.  This  would  also  eliminate  the  need 
for  an  Ingress  version  of  the  database  system. 

The  AFIT/LMG  Database  Management  System  is  a  large  and 
complex  software  development  effort  that  should  proceed  in  a 
series  of  steps  to  insure  proper  implementation.  The  first 
milestone  should  be  to  finish  and  validate  the  student  education 
plan  program.  During  this  phase,  the  software  needed  to  maintain 
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c.  the  database  should  be  developed  and  tested.  This  would  include 

>* 

faculty,  course,  student,  thesis,  and  sequence  information.  The 
database  works  best  when  all  of  the  relationships  can  be  linked 
together.  The  next  step  is  to  completely  implement  the  database 
within  the  Department  of  Electrical  and  Computer  Engeering.  The 
next  steps  would  be  to  phase  in  the  other  departments  within  the 
School  of  Engineering  and  begin  development  on  the  management 
information  programs.  The  success  of  the  AFIT/ENG  Database 
Management  System  for  Faculty  and  Students  will  depend  upon  the 
software  engineering  and  managerial  abilites  of  those  maintain 
the  system.  It  is  hoped  that  this  thesis  has  provided  a  sound 
foundation  for  that  success. 
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APPENDIX  A 


AF IT/ENG  FACULTY  AND  STUDENT  DATABASE  GENERATION 

The  following  appendix  is  the  source  code  used  by  the  TOTAL 
DBMS  to  define  the  master  files,  variable  files,  data  names,  and 
relationships  for  the  AFIT/ENG  database.  The  data  files,  data 
names,  data  links,  data  sizes,  number  of  logical  records,  record 
length,  and  records  per  blocks  are  all  defined  by  the  database 
generation.  When  the  database  is  first  generated  in  the  form 
below,  all  files  sizes  are  fixed  and  empty. 


BEG IN- DATA- BASE-GENERATION  / 
DATA-BASE-NAME=AFITDB  / 
SHARE- 10  / 
I0AREA=MAS1  / 
I0AREA=MAS2  / 


I0AREA=MAS3 
I0AREA=MAS4 
I0AREA=MAS5 
I0AREA=MAS6 
I0AREA=MAS7 
I0AREA=MAS8 
IOAREA=MAST 
I0AREA=VAR1 
I0AREA=VAR2 
I0AREA=VAR3 
I0AREA=VAR4 
IOAREA= VAR5 
IOAREA= VART 
IOAREA= VARX 

END- 10 


THIS  IS  THE  NEW  VERSION  OF  THE  / 
EXPANDED  AF ITDATABASE .  / 

DEVICES  ARE  LISTED  AS  RA81  INSTEAD  / 
OF  RK07 .  THE  TITLE  OF  THIS  IS  / 
AFITDB . DBG  RLE  16  AUG  1985  / 
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BEG IN-MASTER- 

DATA-  SET-  NAME 

IOAREA=MAS  5 

MASTER- DATA 

FACTR00T=8 

FACTCTRL=9 

FACTLKSE=  8 

FACTLKSO=  8 

FACTLKED=8 

FACTLKHA=  8 

FACTLKIN=8 

FACTLKC0=8 

FACTLKTD=8 

FACTLKCM=8 

FACTLKTH=8 

FACTLKCQ=8 

FACTLKPD=8 

FACTLKTA=8 

FACTLKIS=8 

FACTLKAD=8 

FACTLKTC=8 

FACTNAME=  28 

FACTRANK=  3 

FACTSRVC=2 

FACTDOCM=  6 

FACTHDAT=6 

FACTSALR=5 

FACTD0BI=6 

FACTSEXX= 1 

FACTAERO= 10 

FACTDTSC=6 

FACTPMSC=6 

FACTD0RK=6 

FACTYRSS=  2 

FACTADDR=40 

FACTHPHN=7 
FACTEADR=40 
FACTMSTA= 1 
FACTS POS= 12 
FACTSD0B=6 
FACTNDEP=  2 
FACTRACE=  2 
FACTRELN=  2 
FACT0FIC=1 2 
FACTOPHN=  7 
FACTLORG=  50 
FACTTITL=  50 
FACTDEPT=  6 
END- DATA 


MASTER  FACULTY  FILE 


DATA-SET 

=FACT  /  FACULTY  MASTER  / 


/  FACULTY  SSN  / 

/  SECTION  LINK  / 

/  SOCIETY  LINK  / 

/  EDUCATION  LINK  / 

/  HONORS  &  AWARDS  LINK  / 

/  INTEREST  LINK  / 

/  PUBLICATIONS  &  PRESENTAIONS  LINK  / 

/  TDY  LINK  / 

/  DEPT  &  COMMITTEE  LINK  / 

/  LINK  TO  THESIS  / 

/  GRADE  LINK  / 

/  LINK  TO  PROFESSIONAL  DEV  QTR  / 

/  LINK  TO  THESIS  ADVISOR  / 

/  LINK  TO  INSTRUCTOR  STATISTICS  / 

/  LINK  TO  FACULTY  ADVISOR  / 

/  LINK  TO  THESIS  COMMITTEE  MEMBER  / 

/  FACULTY  MEMBERS  NAME , LAST , FIRST, MI/ 

/  MIL/CIV  RANK  (0-OFFICER,G-CIV,NN-RANK) / 
/  MILITARY  SERVICE  / 

/  DATE  OF  COMMISSION  / 

/  DATE  HIRED  / 

/  SALARY  / 

/  DATE  OF  BIRTH  / 

/  SEX  / 

/  AERO  RATING  / 

/  DUTY  AFSC  / 

/  PRIMARY  AFSC  / 

/  DATE  OF  RANK  / 

/  YEARS  OF  SERVICE  / 

/  CURRENT  ADDRESS  -/ 

/  NUMBER, STREET, CITY, STATE, ZIP/ 

/  HOME  PHONE  ( EXCHANGE , EXTENS ION) / 

/  EMERGENCY  ADDRESS  / 

/  MARITAL  STATUS  / 

/  SPOUSE  FIRST  NAME  / 

/  SPOUSE  DATE  OF  BIRTH  / 

/  NUMBER  OF  DEPENDENTS  / 

/  RACE  / 

/  RELIGION  / 

/  OFFICE  RM  NUMBER  / 

/  OFFICE  PHONE  ( EXCHANGE , EXTENS ION) / 

/  LAST  ORGANIZATION  / 

/  LAST  POSITION  TITLE  / 

/  EXPECTED  AFIT  DEPARTURE  DATE  / 


TOTAL-LOGICAL-RECORDS=1000 

LOGICAL-RECORD-LENGTH=462 


/  BLOCKS  I ZE= 2 560 


LOGICAL-RECORDS-PER-BLOCK=  5 
DEVICE=RA81 
DRIVE=30, 5000, DU3 
END-MASTER- DATA-SET 
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MASTER  DEPARTMENT  FILE 


BEGIN-MASTER- DATA-SET 

D AT A- SET- NAME = DEPT  /  DEPARTMENT  MASTER  / 

I0AREA=MAS2 

MASTER- DATA 

DEPTR00T=8 

DEPTCTRL=  4  /  DEPT  CODE  / 

DEPTLKCM*  8  /  DEPT  &  COMMITTEE  LINK  / 

DEPTNAME=  20 
END- DATA 

TOTAL-LOGICAL-RECORDS=  200 
LOG ICAL- RECORD- LENGTH=  40 

LOG I CAL- RECORDS- PER- BLOCK= 1 2  /  BLOCKS IZE= 51 2  / 

DEVICE=RA81 

DRIVE*  31 , 5000 / DU 3 

END-MASTER- DATA-SET 


MASTER  STUDENT  FILE 


BEG IN-MASTER- 

DATA-SET 

DATA-  SET-  NAME 

=  STDT  / 

IOAREA=MAS  4 

MASTER-DATA 

STDTROOT=8 

/ 

STDTCTRL=9 

/ 

STDTLKAW=8 

/ 

STDTLKCR*  8 

/ 

STDTLKDG*  8 

/ 

STDTLKCQ*  8 

/ 

STDTLKTH*  8 

/ 

STDTLKSE=8 

/ 

STDTLKTA*  8 

/ 

STDTLK IS=  8 

/ 

STDTLKAD*  3 

/ 

STDTLKCM*  8 

/ 

STDTSEQN*  3 

/ 

STDTNAME*  2  3 

/ 

STDTRANK*  3 

/ 

/ 

STDTGRAD* 1 

/ 

STDTSRVC*  2 

/ 

STDTAERO=10 

/ 

STDTDORK*  6 

/ 

STDTDOCM*  6 

/ 

STDTYRSS*  2 

/ 

STDTSEXX* 1 

/ 

STDTBOXN*  4 

/ 

STDTDTSC*  6 

/ 

STDTPMSC*  6 

/ 

STDTADDR*  4  0 

/ 

STDTEADR*  40 

/ 

STDTHMPH*  7 

/ 

STDTDTPH*  7 

/ 

STUDENT  MASTER  / 


REQUIRED  / 

STUDENT  SOCIAL  SECURITY  / 

LINK  TO  VHAW  (AWARDS)  / 

LINK  TO  CRSE  (COURSE)  / 

LINK  TO  VEDU  (VARIABLE  EDUCATION)  FILE  / 
LINK  TO  VCQR  (AFIT  COURSES  &  CREDITS  / 

LINK  TO  THESIS  FILE  / 

LINK  TO  SECTION  FILE  / 

LINK  TO  THESIS  ADVISOR  / 

LINK  TO  INSTRUCTOR  STATISTICS  / 

LINK  TO  FACULTY  ADVISOR  / 

LINK  TO  THESIS  COMMITTEE  MEMBER  / 

MASTER  SEQUENCE  CONTROL  NUMBER  */ 

STUDENT  NAME  { LAST , F I RST , MI )  / 

MIL/CIV  RANK ( O-OFF ICER , G-C I V , NN-RANK  / 

HAS  STUDENT  ALREADY  GRADUATED/ LEFT  AFIT?  / 
MILITARY  SERVICE  / 

AERO  RATING  / 

DATE  OF  RANK  / 

DATE  OF  COMMISSION  / 

YEARS  OF  SERVICE  / 

SEX  / 

BOX  NUMBER  / 

DUTY  AFSC  / 

PRIMARY  AFSC  / 

CURRENT  ADDRESS  / 

EMERGENCY  ADDRESS  / 

HOME  PHONE  NUMBER  / 

DUTY  PHONE  NUMBER  / 


STDTEDCD=  5 
STDTD0BH=6 
STDTP0BH=4  0 
STDTMSTA=1 
STDTSP0S=12 
STDTSDOB=  6 
STDTMSPS=1 
STDTNDEP=2 
STDTRACE=  2 
STDTRELN=  2 
STDTLCMD=  5 
STDTLORG*  50 
STDTTITL*  50 
STDTDURN*  2 
END- DATA 


/  EDUCATION  CODE  / 

/  DATE  OF  BIRTH  / 

/  PLACE  OF  BIRTH  / 

/  MARITAL  STATUS  -  M (MARRIED) , D ( IVORCED) , ETC 
/  SPOUSE  FIRST  NAME  / 

/  SPOUSE  DATE  OF  BIRTH  / 

/  MILITARY  SPOUSE  / 

/  NUMBER  OF  DEPENDENTS  / 

/  RACE  / 

/  RELIGION  / 

/  LOSING  COMMAND  / 

/  LAST  ORGANIZATION  / 

/  LAST  POSITION  TITLE  / 

/  DURATION  AT  LAST  DUTY  ASSIGNMENT  / 


TOTAL-LOGICAL-RECORDS*  50  0  0 
LOG ICAL-RECORD-LENGTH*  460 

LOGICAL- RECORDS-PER-BLOCK= 5  BLOCKS  I ZE= 2 3 0 0  MAS1=2560 

DEVICE=RA8l 

DRIVE=  26 , 5000  »  DU3 


END-MASTER- DATA-SET 


MASTER  THESIS  NUMBER  FILE 


BEGIN-MASTER-DATA-SET 

DATA-SET-NAME=THES  /  THESIS  NUMBER  MASTER  / 

IOAREA=MAS6 


MASTER- DATA 
THESROOT=8 
THESCTRL=10 
THESLKTH=  8 
THESLKTA=  8 
THESLKTC=8 
THESTITL=  50 
THESSPON=  50 
THESLOCN*  50 
THESCLAS* 1 2 
THESNAME=28 
END-DATA 


/  THESIS  CATALOGING  NUMBER  / 

/  LINK  TO  VARIABLE  THESIS  TITLE  FILE  / 
/  LINK  TO  THESIS  ADVISOR  / 

/  LINK  TO  THESIS  COMM  MEMBER  FILE  / 

/  THESIS  TITLE  / 

/  THESIS  SPONSOR  / 

/  THESIS  LOCATION  / 

/  THESIS  CLASSIFICATION  / 

/  STUDENT  NAME  FOR  ARCHIVE  PURPOSES  / 


TOTAL-LOGICAL- RECORDS* 5000 
LOGICAL- RECORD- LENGTH* 232 
LOG I CAL- RECORDS -PER- BLOCK*  4 
DEVICE=RA81 
DRIVE=22, 5000/DU3 


END-MASTER-DATA-SET 


MASTER  SECTION  NUMBER  FILE 


BEGIN-MASTER- DATA-SET 

DATA- SET- NAME= SECT  /  SECTION  NUMBER  MASTER  FILE  / 

IOAREA=MAS6 

MASTER-DATA 
SECTROOT=8 
SECTCTRL=8 
SECTLKSE=8 
SECTLKAD=8 
SECTLSSN=9 
SECTGRDT=6 
SECTENDT=6 
SECTNRSN=3 
END- DATA 

TOTAL-LOGICAL-RECORDS=  500 
LOGICAL-RECORD-LENGTH=  56 
LOGICAL-RECORDS-PER-BLOCK=  9 
DEVICE=RA81 
DRIVE=23, 5000, DU3 


/  SECTION  NUMBER  (EX.,  GCS-84D)  / 
/  LINK  TO  SECTION  LEADER  FILE  / 

/  LINK  TO  FACULTY  ADVISOR  / 

/  SECTION  LEADER  SSSN  / 

/  GRADUATION  DATE  / 

/  ENTRY  DATE  / 

/  NUMBER  OF  STUDENTS  IN  SECTION  / 


END-MASTER- DATA-SET 


MASTER  COURSE  FILE 


\ 


BEGIN-MASTER- DATA-SET 
DATA-SET- NAME=MCRS 
IOAREA=MAS  3 

MASTER- DATA 
MCRSROOT=8 
MCRSCTRL=8 
MCRSCRHR= 1 
MCRSLKCQ=8 
MCRSLKRQ=3 
MCRSLKCB=8 
MCRSLKSC3  8 
MCRSLKSS=8 
MCRSLKIS3  8 
MCRSLCHR=1 
MCRSLBHR= 1 
MCRSSZLM* 2 
MCRSTITL=  50 
MCRSREST3 I 
END- DATA 
DEVICE=RA8I 

TOTAL -LOGICAL -RECORDS3  2000 
LOG ICAL- RECORD- LENGTH3 130 
LOGICAL- RECORDS-PER-BLOCK= 7 
DRIVE3 12 , 5000 , DU3 
END-MASTER- DATA- SET 


/  COURSE  DATA  MASTER  FILE  / 


/  REQUIRED  BY  TOTAL  / 

/  COURSE  NUMBER  / 

/  COURSE  CREDIT  HOURS/ 

/  LINK  TO  QUARTER  / 

/  LINK  TO  REQUISITE  / 

/  LINK  TO  BOOK  TITLE  / 

/  LINK  TO  SCHD  / 

/  LINK  TO  COURSE  SEQUENCE  / 

/  LINK  TO  INSTRUCTOR  STATISTICS  / 

/  COURSE  LECTURE  HOURS  DATA  / 

/  COURSE  LAB  HOUR  DATA  / 

/  SIZE  LIMIT  DATA  / 

/  TITLE  DATA  / 

/  RESTRICTED  (FROM  GRAD  REQ)  COURSE  / 


/  BLOCKSIZE  =  1024  / 


MASTER  QUARTER  FILE 


BEGIN-MASTER- DATA-SET 
DATA-SET- NAME=MQTR 
I0AREA=MAS7 

MASTER- DATA 
MQTRR00T=8 
MQTRCTRL=  4 
MQTRLKCT=8 
MQTRLKPD=8 
MQTRSTDT=6 
MQTRSPDT=6 
END- DATA 

DEVICE=RA81 

TOTAL- LOGICAL- RECORDS= 1 000 
LOGICAL-RECORD-LENGTH=4  0 
L0GICAL-REC0RDS-PER-3L0CK= 12 
DRIVE=13 ,  5000 , DU 3 
END-MASTER-DATA-SET 


/  QUARTER  DATA  MASTER  FILE  / 


/  REQUIRED  BY  TOTAL  / 

/  QUARTER  NUMBER  / 

/  LINK  TO  COURSE  / 

/  LINK  TO  PROF  DEV  QTR  / 

/  QUARTER  START  DATE ( DAY , MO, YR)  / 
/  QUARTER  STOP  DATE  ( DAY ,MO, YR)  / 


MASTER  BOOK  FILE 


/  BOOK  INFORMATION  MASTER  FILE  / 


BEGIN-MASTER- DATA-SET 
DATA- SET- NAME = MB KT 
IOAREA=MASl 
MASTER- DATA 


MBKTROOT=8  / 
MBKTCTRL=40  / 
MBKTLKBK=8  / 
MBKTLKNO=8  / 
MBKTATHR=  28  / 
MBKTPUBL=28  / 
MBKTNAVL=6  / 
MBKTPRCE=  4  / 
END- DATA 


DEVICE=RA81 

TOTAL-LOGICAL-RECORDS=  5000 
LOG ICAL- RECORD- LENGTH= 130 
LOGICAL- RECORDS -PER-BLOCK=  3 
DRIVE=14, 5000, DU3 
END-MASTER- DATA-SET 


REQUIRED  BY  TOTAL  / 

BOOK  TITLE  NAME  / 

LINK  TO  COURSE  THRU  VCBK  / 

LINK  TO  NUMBER  ORDERED  / 

BOOK  AUTHOR  NAME  ( LAST , F IRST , MI )  / 
BOOK  PUBLISHER  NAME  / 

NUMBER  OF  BOOKS  AVAILABLE  / 

BOOK  PRICE  / 


PHYSICAL  ENVIRONMENT 


MASTER  ORDER  FILE 


BEGIN-MASTER- DATA-SET 

DATA-SET- NAME=MORD 

IOAREA=MASl 

MASTER-DATA 

MORDROOT=8 

MORDCTRL=7 

MORDLKBO=8 

MORDORDT=6 

MORDDUDT=6 

MORDCMPY=  2  0 

MORDADDR=  40 

MORDPHNE=10 

END- DATA 


/  BOOK  ORDERING  INFORMATION  MASTER  FILE  / 


/  REQUIRED  BY  TOTAL  / 

/  MASTER  ORDER  NUMBER  / 

/  LINK  TO  BOOK  THRU  VNMO  / 

/  ORDER  NUMBER  / 

/  DUE  DATE  / 

/  COMPANY  / 

/  COMPANY  ADDRESS  / 

/  COMPANY  PHONE  NUMBER  WITH  AREA  CODE  / 


DEVICE=RA8l  PHYSICAL  ENVIRONMENT 

TOTAL-LOGICAL-RECORDS  =  10  0  0 

LOGICAL-RECORD-LENGTH=106 

LOG ICAL- RECORDS- PER- BLOCK= 4 

DRIVE* 15 »  5000 / DU 3 

END-MASTER-DATA-SET 


-  MASTER  CLASS  TIME  FILE  - 

BEGIN-MASTER-DATA-SET 

DATA-SET-NAME-TIME  /  MASTER  CONTAINING  COURSE  TIMES  / 

IOAREA=MAST 

MASTER-DATA 

TIMEROOT=8 

TIMECTRL=4  /  MILITARY  CLOCK  TIME  / 

TIMELKSC=8  /  LINKPATH  TO  SCHEDULE  FILE  / 

END- DATA 

TOTAL- LOGICAL- RECORDS* 3600 
LOGICAL-RECORD-LENGTH* 20 
LOGICAL- RECORDS -PER- BLOCK*  25 
DEVICE=RA8 1 
DRIVE*  01 , 5000  » DU 3 
END-MASTER- DATA-SET 


MASTER  BUILDING/ROOM  FILE 


BEGIN-MASTER-DATA-SET 


DATA- SET- NAME =BLRM  / 

/ 

IOAREA=MAST 
MASTER- DATA 
BLRMROOT=8 

BLRMCTRL=8  / 
BLRMLKSC=8  / 
BLRMLKCL*  8  / 


MASTER  CONTAINING  ROOMS  AND  / 
BLDG  #'S  FOR  SCHEDULING  / 


BUILDING  AND  ROOM  NUMBER  / 
LINKPATH  TO  SCHEDULE  FILE  / 
LINKPATH  TO  CLASSROOM  FILE  / 


END-DATA 


TOTAL-LOGICAL-RECORDS=  5000 
LOGICAL-RECORD-LENGTH=  32 
LOG ICAL- RECORDS- PER- BLOCK= 16 
DEVICE=RA8 1 
DRIVE=02 ,5000 /DU  3 
END-MASTER-DATA-SET 


MASTER  ROOM  CAPACITY  FILE 


BEGIN-MASTER-DATA-SET 

DATA-SET-NAME=CPTY  /  MASTER  CONTAINING  ROOM  CAPACITIES  / 

IOAREA=MAST 

MASTER-DATA 

CPTYROOT=8 

CPTYCTRL3  4  /  CAPACITY  NUMBER  / 

CPTYLKCL=8  /  LINKPATH  TO  CLASSROOM  FILE  / 

END- DATA 

TOTAL- LOG ICAL- RECORDS3  700 
LOGICAL-RECORD-LENGTH=  20 
LOGICAL- RECORDS-PER-BLOCK=  25 
DEV ICE= RA 8 1 
DRIVE3 03 /  5000  ,  DU3 
END-MASTER- DATA-SET 


MASTER  DAY  SCHEDULING  FILE 


BEGIN-MASTER-DATA-SET 

DATA-SET- NAME3 DAY S  /  MASTER  WHICH  CONTAINS  DAYS  OF  WEEK  / 

IOAREA-MAST 

MAS TER- DATA 

DAYS ROOT3 8 

DAYSCTRL=4  /  DAY  OF  THE  WEEK  / 

DAYSLKSC=8  /  LINKPATH  TO  SCHEDULE  FILE  / 

END- DATA 

TOTAL-LOGICAL-RECORDS3 30 
LOGICAL-RECORD-LENGTH3 20 
LOG I CAL- RECORDS -PER- BLOCK3  25 
DEVICE=RA81 
DRIVE3 04  f  5000  f  DU 3 
END-MASTER- DATA-SET 
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MASTER  SEQUENCE  FILE 


BEG IN-MASTER- DATA-SET 

DATA- SET- NAME=MSSF  /  COURSE  SEQUENCES  MASTER  / 

IOAREA=MAS8 

MASTER- DATA 

MSSFROOT=8 

MSSFCTRL=  3  /  COURSE  SEQUENCE  NUMBER  /  . 

MSSFSEQN=40  /  SEQUENCE  NAME  / 

MSSFLKSS=  8  /  VARIABLE  SEQUENCE  FILE  LINK  / 

END- DATA 

TOTAL- LOG I CAL- RECORDS  =  5000 
LOGICAL- RECORD- LENGTH= 6  0 

LOGICAL-RECORDS-PER-BLOCK=8  /  BLOCKS IZE= 512  / 

DEVICE=RA81 

DRIVE=  42 / 5000  »  DU 3 

END-MASTER- DATA-SET 


MASTER  DEGREE  REQUIREMENTS  FILE 


BEGIN-MASTER- DATA-SET 

DATA- SET- NAME=MDEG 

IOAREA=MAS8 

MASTER- DATA 

MDEGROOT=8 

MDEGCTRL=  2 

MDEGNAME-40 

MDEGLKCR=8 

MDEGLKSS=8 

END- DATA 


/  DEGREE  REQUIREMENTS  MASTER  / 


/  NUMBER  IDENTIFYING  TYPE  GRAD  DEGREE  / 
/  NAME  OF  TYPE  OF  DEGREE  / 

/  COURSE  LINK  / 

/  COURSE  SEQUENCE  LINK  / 


TOTAL- LOG I CAL- RECORDS =  5000 
LOGICAL- RECORD- LENGTH= 6 6 

LOGICAL-RECORDS-PER-BLOCK=  7  /  BLOCKSIZE= 512  / 

DEVICE=  RA8 1 
DRIVE=  43  f  5000  »  DU 3 
END-MASTER- DATA-SET 


BEG IN- VARIABLE- ENTRY- DATA-SET 


DATA- SET- NAME =VEDU 

I0AREA=VAR1 

3ASE-DATA 

VEDUFSSN=9 

FACTLKED=8=VEDUFSSN 

VEDUSTDT=9 

STDTLKDG=8=VEDUSTDT 

VEDUUNIV=40 

VEDUDEGR=40 

VEDUYEAR=4 

END- DATA 


/  EDUCATION  VAR  FILE  / 


/ 

/ 

/ 

/ 

/ 

/ 

/ 


FACULTY  SSN  / 

LINK  TO  FACULTY  MASTER  / 

STUDENT  SSN  / 

LINK  TO  STUDENT  MASTER  / 

INSTITUTION  (UNIVERSITY)  ATTENDED  / 
DEGREE  EARNED  / 

YEAR  DEGREE  AWARDED  / 


DEVICE=RA81 
DRIVE=32, 5000, DU3 
TOTAL-LOGICAL-RECORDS=  50  0  0 
LOGICAL- RECORD-LENGTH= 120 
LOGICAL-RECORDS-PER-BLOCK=  4 
END- VARIABLE-ENTRY- DATA-SET 


/  BLOCKS  I ZE=  512  / 


VARIABLE  FACULTY  SOCIETY  FILE 


BEGIN-VARIABLE-ENTRY-DATA-SET 


DATA-SET-NAME=FSOC 
IOAREA=VARl 
BASE-DATA 
FSOCFSSN=9 
FACTLKSO=8=FSOCFSSN 
FSOCSOCY=  40 
FSOCDUMl=  8 
END- DATA 


/  SOCIETY  VAR  FILE  / 


/  FACULTY  SSN  / 


/  SOCIETIES  TO  WHICH  INDIVIDUAL  BELONGS  / 
/  PADDING  TO  INCREASE  REC  LENGTH  / 


DEVICE=RA81 
DRIVE=33 , 5000 »  DU 3 
TOTAL-LOGICAL-RECORDS= 100  00 
LOGICAL- RECORD- LENGTH= 6 6 
LOG ICAL- RECORDS -PER-B LOCK =  7 
END- VARIABLE-ENTRY-DATA-SET 


/  BLOCKSIZE=512  / 


VARIABLE  FACULTY  DEPT  &  COMMITTEE  FILE 


BEGIN-VARIABLE-ENTRY-DATA-SET 

DATA-SET-NAME= FCMT 

IOAREA= VAR1 

BASE-DATA 

FCMTCODE=  2 

FCMTFSSN=9 

FACTLKCM=  8  =  FCMTFSSN 

FCMTDCOD=  4 

DEPTLKCM=8=FCMTDCOD 

FCMTDATA= 1 4 


/  DEPT  AND  COMMITTEE  VAR  FILE  / 


/  FACULTY  SSN=9  / 

/  LINK  TO  FACULTY  MASTER  SSN  / 

/  DEPARTMENT  DCOD  / 

/  LINK  TO  DEPT  MASTER  DEPT  CODE  / 
/  REDEFINED  DATA  AREA  LENGTH  / 
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v, 


RECORD-CODE=DP  /  COMMITTEE  MEMBERSHIP  / 

RECORD-CODE=CM  /  ADDITIONAL  COMMITTEE  MEMBERSHIPS  / 

END- DATA 

DEVICE=RA81 
DRIVE®  34/  5000 » DU  3 
TOTAL- LOGICAL-RECORDS=  5000 
LOG ICAL- RECORD- LENGTH®  46 

LOGICAL- RECORDS- PER- BLOCK® 11  /  BLOCKS IZE® 51 2  / 

END-VARIABLE-ENTRY-DATA-SET 


-  VARIABLE  HONORS  &  AWARDS  FILE  - 

BEGIN- VARIABLE-ENTRY-DATA-SET 

DATA-SET-NAME® VHAW  /  HONORS  &  AWARDS  VAR  FILE  / 

IOAREA=VARl 

BASE-DATA 

VHAWCODE=2 

VHAWFSSN=9  /  FACULTY  SSN  / 

FACTLKHA=8= VHAWFSSN  /  LINK  TO  FACULTY  SSN  / 

VHAWSTDT=9  /  STUDENT  SOCIAL  SECURITY  NUMBER  / 

STDTLKAW=8=VHAWSTDT  /  LINK  TO  STDT  (STUDENT  MASTER)  / 
VHAWDATA® 1 6  /  REDEFINING  DATA  LENGTH  AREA  / 

RECORD-CODE=HN  /  HONOR  AREA  / 

RECORD- CODE® AW  /  AWARD  AREA  / 

END- DATA 

DEV ICE® RA 81 
DRIVE® 3 6 , 5000 » DU 3 
TOTAL- LOGICAL- RECORDS® 1 0000 
LOGICAL-RECORD-LENGTH®  54 

LOG I CAL- RECORDS- PER- BLOCK® 9  /  BLOCKS IZE® 51 2  / 

END- VARIABLE-ENTRY- DATA-SET 


-  VARIABLE  FACULTY  INTERESTS  FILE  - 

BEGIN- VARIABLE- ENTRY- DATA-SET 

DATA-SET- NAME® FINT  /  INTEREST  AREA  VAR  FILE  / 

IOAREA® VAR1 
BASE- DATA 

F INTFSSN® 9  /  FACULTY  SSN  / 

FACTLKIN=8=F INTFSSN  /  LINK  TO  FACULTY  SSN  / 

FINTAREA=15  /  AREA  OF  INTEREST  / 

END-DATA 

DEVICE=RA81 
DRIVE=37, 5000, DU3 
TOTAL-LOGICAL-RECORDS® 10000 
LOGICAL-RECORD-LENGTH®  3  4 

LOGICAL-RECORDS-PER-BLOCK® 1 6  /  BLOCKS IZE® 51 2  / 

END- VARIABLE-ENTRY- DATA-SET 


-  VARIABLE  FACULTY  PUBS  AND  PRESENTATIONS  - 

BEGIN- VARIABLE-ENTRY- DATA-SET 

DATA-SET-NAME=FCOM  /  PUBLICATIONS  &  PRESENTATIONS  VAR  FILE  / 

IOAREA=VARl 

BASE- DATA 

FCOMCODE=2 

FCOMFSSN=9  /  FACULTY  SSN  / 

FACTLKCO=8=FCOMFSSN  /  LINK  TO  FACULTY  FSSN  / 

FCOMDATA=61  /  REDEFINED  DATA  AREA  LENGTH  / 

RECORD-CODE=PB  /  PUBLICATION  DATA  AREA  / 

RECORD-CODE=  PR  /  PRESENTATIONS  DATA  AREA  / 

END- DATA 

DEVICE=RA81 
DRIVE=38, 5000, DU3 
TOTAL-LOG ICAL-RECORDS= 10000 
LOGICAL-RECORD-LENGTH=82 
LOGICAL-RECORDS-PER-BLOCK=  6 
END- VARIABLE- ENTRY- DATA-SET 


-  VARIABLE  FACULTY  TDY  FILE  - 

BEG IN- VARIABLE- ENTRY- DATA- SET 
DATA-SET- NAME=FTDY  /  TDY  VAR  FILE  / 

IOAREA-VAR1 

BASE-DATA 

FTDYFSSN=9  /  FACULTY  SSN/ 

FACTLKTD=8=FTDYFSSN  /  LINK  TO  FACULTY  SSN  / 

FTDYCOST=  7  /  COST  OF  TDY  DATA  IN  THIS  FILE  / 

FTDYDEST=20  /  DESTINATION  / 

FTDYBDAT=6  /  BEGIN  DATE  / 

FTDYEDAT=6  /  END  DATA  / 

END- DATA 

DEVICE=RA81 
DRIVE=  3  9 /  5000, DU3 
TOTAL-LOGICAL- RECORDS= 100 00 
LOG ICAL- RECORD- LENGTH=  58 

LOG ICAL- RECORDS- PER- B LOCK =  9  /  BLOCKSIZE= 512  / 

END- VARIABLE- ENTRY- DATA-SET 


-  VARIABLE  STUDENT  COURSE  FILE 

BEG IN- VARIABLE- ENTRY- DATA-SET 
DATA-SET-NAME=CRSE  /  COURSE  VARIABLE  / 

IOAREA=VAR4 
BASE-DATA 
CRSESTDT=9 
STDTLKCR=8=CRSESTDT 


/  STUDENT  SOCIAL  SECURITY  NUMBER  / 

/  LINK  TO  STUDENT  (STUDENT  MASTER)  / 


CRSEMDEG=  2  /  TY 

MDEGLKCR=8=CRSEMDEG  /  LI 

CRSENUMB=8  /  CO 

CRSENAME=20  /  CO 

CRSEGRAD=  2  /  CO 

CRSEBEGN=4  /  QU 

CRSECOLL=  3  0  /  CO 

CRSEWAIV=1  /  CO 

END- DATA 
DEVICE=RA81 

TOTAL- LOG  ICAL-  RECORDS**  50000 
LOGICAL-RECORD-LENGTH=9  4 
LOGICAL- RECORDS-PER-BLOCK* 11 
DRIVE=27, 10500, DU3 
END-VARIABLE-ENTRY-DATA-SET 


/  TYPE  GRAD  DEGREE  {NUMBER  -  PROM  MDEG)  / 

/  LINK  TO  MASTER  DEGREE  REQUIREMENTS  / 

/  COURSE  NUMBER  / 

/  COURSE  NAME  / 

/  COURSE  GRADE  / 

/  QUARTER  STUDENT  TOOK  OR  WILL  TAKE  COURSE  / 
/  COLLEGE  ATTENDED  / 

/  COURSE  WAIVED?  (Y/N)  / 


/  BLOCKSIZE  =  1024  / 


VARIABLE  THESIS  TITLE  FILE 


BEGIN- VARIABLE-ENTRY- DATA-SET 
DATA- SET- NAME*  THTL  / 
IOAREA=VAR4 


/  VAR  FILE  FOR  STUDENT  THESIS  DATA  / 


BASE-DATA 
THTLTHES= 10 
THESLKTH=8=THTLTHES 
THTLFACT=9 
FACTLKTH=8=THTLFACT 
THTLSTDT»9 
STDTLKTH=8=THTLSTDT 
END- DATA 

TOTAL- LOGICAL- RECORDS= 5000 
LOG ICAL- RECORD- LENGTH=  52 
LOGICAL-RECORDS-PER-BLOCK= 1 0 
DEVICE=RA81 
DRIVE=  24 , 5000, DU3 

END-VARIABLE-ENTRY-DATA-SET 


/  DEPARTMENT  THESIS  NUMBER  / 
/  LINK  TO  THES  / 

/  FACULTY  ADVISOR  FSSN  / 

/  LINK  TO  FACULTY  FSSN  / 

/  STUDENT  SSSN  / 

/  LINK  TO  STUDENT  SSSN  / 


/  BLOCKSIZE  520  / 


VARIABLE  SECTION  LEADER  FILE 


BEGIN- VARIABLE- ENTRY- DATA-SET 

DATA- SET- NAME=SECL  /  VARIABLE  SECTION  LEADER  FILE  / 

IOAREA= VAR3 


BASE-DATA 
SECLSECT=8 
SECTLKSE*  8  =  SECLSECT 
SECLSTDT=9 
STDTLKSE=8=SECLSTDT 
SECLFACT=9 
FACTLKSE=8=SECLFACT 
END- DATA 


/  RELATED  TO  SECT  (SECTION  NUMBER)  / 
/  LINK  TO  SECT  / 

/  STUDENT  SSSN  / 

/  LINK  TO  STUDENT  SSSN  / 

/  FACULTY  FSSN  / 

/  LINK  TO  FACULTY  FSSN  / 


A- 14 


V  V  V  V  -  > 

■  A  ^V-  .Vw*. 


TOTAL -LOGIC AL-RECORDS  =  5000 
LOG ICAL- RECORD- LENGTH=  52 
LOG ICAL- RECORDS- PER- BLOC K= 10 
DEVICE=RA81 
DRIVE=25,  5000/DU3 

END- VARIABLE-ENTRY- DATA-SET 


VARIABLE  QUARTER  FILE 


BEGIN- VARIABLE-ENTRY-DATA-SET 


DATA- SET- NAME=VCQR  / 

IOAREA=VAR5 

BASE-DATA 

VCQRCODE*2 

VCQRNMBR=8  / 

MCRSLKCQ*8=VCQRNMBR  / 

VCQRIDEN=4  / 

MQTRLKCT=8= VCQRIDEN  / 

VCQRDATA*  20  / 

RECORD-CODE=QC  / 

RECORD-CODE=QS  / 

STDTLKCQ=8=VCQRSSSN  / 

RECORD-CODE*  FQ  / 

FACTLKCQ=8=VCQRFSSN  / 

END- DATA 


DEVICE=RA81 

TOTAL-LOGICAL-RECORDS= 50000 
LOG ICAL- RECORD- LENGTH=  50 
LOG  I  CAL- RECORDS -PER-BLOCK-*  1 0 
DRIVE= 16  »  5000, DU3 
END-VARIABLE-ENTRY- DATA-SET 


VARIABLE  QUARTER  FILE  / 


COURSE  NUMBER  CONTROL  FIELD  / 
LINK  FROM  MASTER  COURSE  / 
QUARTER  IDENT  CONTROL  FIELD  / 
LINK  FROM  MASTER  QUARTER  / 
REDEFINED  VAR  QUARTER  DATA  / 


CODE 

IS 

QC 

(FOR 

COURSE) 

/ 

CODE 

IS 

QS 

(FOR 

STUDENT) 

/ 

LINK 

TO 

MASTER  STUDENT  / 

CODE 

IS 

FQ 

(FOR 

FACULTY) 

/ 

LINK 

TO 

FACULTY 

SSN  / 

VARIABLE  REQUISITE  FILE 


BEG IN- VARIABLE- ENTRY -DATA- SET 


DATA- SET- NAME* VREQ  / 

IOAREA* VARX 

BASE-DATA 

VREQCODE*  2  / 

VREQNMBR*  8  / 

MC RSLKRQ*  8= VREQNMBR  / 

VREQDATA=1 4  / 

RECORD- CODE=CR  / 

RECORD-CODE*  PR  / 

END- DATA 


VARIABLE  REQUISITE  FILE  / 


CODED  RECORD  FOR  REQUISITE  / 
COURSE  NUMBER  CONTROL  FIELD  / 
LINK  FROM  MASTER  COURSE  / 
REDEFINED  REQUISITE  DATA  / 
CODE  IS  COREQUISITE  / 

CODE  IS  PREREQUISITE  / 


DEVICE=RA81 

TOTAL-LOGICAL- RECORDS* 5000 
LOG I CAL- RECORD- LENGTH*  3  2 


LOG ICAL- RECORDS- PE R-BLOCK= 18 

DRIVE=17 , 5000 , DU3 

END- VARIABLE- ENTRY-DATA-SET 


VARIABLE  BOOK  LINK  FILE 


VARIABLE  BOOK  LINK  FILE  / 


COURSE  NUMBER  CONTROL  FIELD  / 
LINK  FROM  MASTER  COURSE  / 

BOOK  TITLE  CONTROL  FIELD  / 
LINK  FROM  MASTER  BOOK  TITLE  / 


DEVICE=RA81 

TOTAL- LOGICAL-RECORDS= 5000 
LOGICAL- RECORD- LENGTH^ 6  4 
LOG I CAL- RECORDS- PER- BLOCK=  8 
DRIVE=19, 5000, DU3 
END-VARIABLE-ENTRY-DATA-SET 


BEGIN- VARIABLE- ENTRY- DATA-SET 


DATA- SET- NAME =VCBK  / 

IOAREA=VARX 

BASE-DATA 

VCBKNMBR=8  / 

MCRSLKCB=8=VCBKNMBR  / 

VCBKTITL=  40  / 

MBKTLKBK=8=VCBKTITL  / 

END- DATA 


VARIABLE  NUMBER  ORDERED  FILE 


BEGIN- VARIABLE-ENTRY-DATA-SET 


DATA-SET-NAME= VNMO  / 

/ 

IOAREA= VARX 
BASE- DATA 

VNMOTITL=40  / 

MBKTLKNO=8=VNMOTITL  / 

VNMONMBR=  7  / 

MORDLKBO=8=VNMONMBR  / 

VNMONORD=  3  / 

END- DATA 


DEVICE=RA81 

TOTAL-LOG ICAL- RECORDS=  5000 
LOG ICAL- RECORD- LENGTH =  6  8 
LOG I CAL- RECORDS- PER- BLOCK  =  7 
DRIVE=20 , 5000, DU3 
END- VARIABLE-ENTRY- DATA-SET 


VARIABLE  NUMBER  OF  TEXTS/ 
ORDERED  FILE  / 


BOOK  TITLE  CONTROL  FIELD  / 

LINK  FROM  MASTER  BOOK  TITLE  / 
ORDER  NUMBER  CONTROL  FIELD  / 
LINK  FROM  MASTER  ORDER  NUMBER  / 
NUMBER  ORDERED  DATA  ITEM  / 


VARIABLE  CLASS  SCHEDULE  FILE 


BEGIN- VAR I ABLE- ENTRY- DATA-SET 

DATA- SET- NAME = SC HD  /  VAR  FILE  TO  CONTAIN  CLASS  DATA 

IOAREA= VART 

BASE-DATA 

SCHDNSTD=  3  /  NUMBER  OF  STUDENTS  IN  CLASS  / 

SCHDNMBR=  8  /  COURSE  NUMBER  / 


/ 
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MCRSLKSC=8=SCHDNMBR  /  LINKPATH  TO  COURSE  NUMBER  FILE  / 
SCHDDAYS=  4  /  DAY  CLASS  MEETS  / 

DAYSLKSC=8=SCHDDAYS  /  LINKPATH  TO  DAYS  FILE  / 

SCHDTIME=  4  /  TIME  CLASS  STARTS  / 

TIMELKSC=8=SCHDTIME  /  LINKPATH  TO  TIME  FILE  / 

SCHDBLRM=8  /  BUILDING  AND  ROOM  NUMBER  / 

BLRMLKSC=  8  =  SCHDBLRM  /  LINKPATH  TO  BUILDING  AND  ROOM  FILE  / 

SCHDFNTM=4  /  CLASS  FINISH  TIME  / 

END-DATA 

DEVICE=RA81 

TOTAL-LOGICAL-RECORDS=  5000 
LOGICAL-RECORD-LENGTH=6  4 
LOG I CAL- RECORDS -PER-BLOCK= 8 
DRIVE=05, 5000, DU3 
END-VARIABLE-ENTRY-DATA-SET 


-  VARIABLE  CLASSROOM  FILE  - 

BEG IN- VARIABLE- ENTRY- DATA- SET 

DATA- SET- NAME=CLSR  /  FILE  TO  CONTAIN  CLASSROOM  DATA  / 

IOAREA= VART 
BASE-DATA 

CLSRBLRM=8  /  BUILDING  AND  ROOM  NUMBER  / 

BLRMLKCL=8=CLSRBLRM  /  LINKPATH  TO  BUILDING  AND  ROOM  FILE  / 

CLSRCPTY=  4  /  CAPACITY  OF  ROOM  / 

CPTYLKCL=8=CLSRCPTY  /  LINKPATH  TO  CAPACITY  FILE  / 

CLSREQPT=  2  /  TYPE(S)  OF  EQUIPMENT  IN  ROOM  / 

CLSRTYPE=  3  /  CODE  FOR  TYPE  OF  ROOM  / 

CLSRCFLG= 1  /  CODE  FOR  SECURITY  CLASSIFICATION  LEVEL  OF  ROOM 

END- DATA 

DEVICE=RA81 

TOTAL- LOG ICAL- RECORDS= 5000 
LOGICAL- RECORD- LENGTH= 3 4 
LOGICAL- RECORDS- PER-BLOCK=l 4 
DRIVE  =  06  ,  5000, DU3 
END- VAR IABLE-ENTRY- DATA- SET 


-  VARIABLE  THESIS  COMMITTEE  MEMBER  FILE  - 

BEG IN- VARIABLE- ENTRY- DATA-SET 

DATA- SET- NAME =TCMF  /  VAR  THESIS  COMM  MEMBER  FILE  / 

IOAREA=VAR3 

BASE-DATA 

TCMFFACT=9  /  FACULTY  SSN  / 

FACTLKTC=8=TCMFFACT  /  LINK  TO  FACULTY  FSSN  / 

TCMFSTDT=  9  /  STUDENT  SSN  / 

STDTLKCM=8=TCMFSTDT  /  LINK  TO  STUDENT  SSSN  / 

TCMFTHES= 1 0  /  DEPARTMENT  THESIS  NUMBER  / 

THESLKTC=8=TCMFTHES  /  LINK  TO  THESIS  DEPARTMENT  NUMBER  / 

END- DATA 


TOTAL- LOGICAL-RECORDS* 5000 
LOGICAL- RECORD-LENGTH*  54 
LOGICAL- RECORDS- PER- BLOCK* 9 
DEVICE=RA81 
DRIVE=44 , 5000, DU3 

END- VARIABLE-ENTRY- DATA-SET 


-  VARIABLE  FACULTY  ADVISER  FILE  - 

BEGIN-V-aRIABLE- ENTRY- DATA-SET 

DATA-SET-NAME=FADV  /  VARIALE  FACULTY  ADVISOR  FILE  / 

IOAREA=VAR3 

BASE-DATA 

FADVSECT=8  /  SECT  CTRL  (SECT  NUMBER)  / 

SECTLKAD=8=FADVSECT  /  LINK  TO  SECT  / 

F ADVSTDT=9  /  STUDENT  SSSN  / 

STDTLKAD=8=FADVSTDT  /  LINK  TO  STUDENT  SSSN  / 

FADVFACT=9  /  FACULTY  FSSN  / 

FACTLKAD=8=FADVFACT  /  LINK  TO  FACULTY  FSSN  / 

END- DATA 

TOTAL-LOGICAL- RECORDS= 5000 
LOGICAL-RECORD-LENGTH=  52 
LOG I CAL- RECORDS -PER- BLOCK* 1 0 
DEVICE=RA8I 
DRIVE* 4 5 , 5000 , DU  3 

END- VARIABLE- ENTRY- DATA-SET 


VARIABLE  INSTRUCTOR  STATISTICS  FILE 


BEGIN- VARIABLE- ENTRY- DATA-SET 


DATA-SET- NAME* VINS 
IOAREA= VAR1 


/  INST  STATS  FOR  USE  WITH/ 
/  INSTRUCTOR  LOAD  DATA  / 


BASE-DATA 
VI NSSTDT*  9 
3TDTLK IS*  8  =  VI NSSTDT 
VINSNMBR*  8 
MCRSLKIS=8=VINSNMBR 
VINSFACT=9 
FACTLKIS=8=VINSFACT 
END- DATA 


/  STUDENT  SSSN  / 

/  LINK  TO  STUDENT  SSSN  / 

/  MCRS  CTRL  (COURSE  NUMBER)  / 

/  LINK  TO  MCRS  (MASTER  COURSE  FILE)  / 
/  FACULTY  SSSN  / 

/  LINK  TO  FACULTY  FSSN  / 


TOTAL- LOGICAL- RECORDS*  50  00 
LOGICAL- RECORD- LENGTH* 5 2 
LOGICAL- RECORDS- PER- BLOCK* 10 
DEVICE=RA8 1 
DRIVE*  46 , 5000, DU3 


END- VARIABLE-ENTRY- DATA-SET 


VARIABLE  THESIS  ADVISOR  FILE 


BEG IN- VAR I ABLE- ENTRY- DATA- SET 

DATA- SET- NAME= TAD V  /  VAR  THESIS  ADVISOR  FILE  / 

IOAREA=VAR3 


BASE-DATA 

TADVTHES=10 

THESLKTA=8=TADVTHES 

TADVSTDT=9 

STDTLKTA=8=TADVSTDT 

TADVFACT=9 

FACTLKTA=8=TADVFACT 

END- DATA 


/  IDENTIFIES  TADV 
/  LINK  TO  THES  / 

/  STUDENT  SSSN  / 

/  LINK  TO  STUDENT 
/  FACULTY  FSSN  / 

/  LINK  TO  FACULTY 


TIED  TO  THES  NUMBER  / 

SSSN  / 

FSSN  / 


TOTAL- LOGICAL-RECORDS  =  500  0 
LOGICAL-RECORD-LENGTH=  54 
LOG ICAL- RECORDS- PER-BLOCK  =  9 
DEVICE=RA81 
DRIVE=47, 5000, DU3 


END- VARIABLE-ENTRY-DATA-SET 


t  -  VARIABLE  PROFESSIONAL  DEVELOPMENT  FILE  - 

BEGIN- VARIABLE- ENTRY-DATA-SET 

DATA-SET-NAME= VPDQ  /  VAR  FILE  TO  DET  INST  PROF  DEV  QTRS  / 

IOAREA=VAR2 


BASE- DATA 
VPDQMQTR=  4 
MQTRLKPD=3=VPDQMQTR 
VPDQFACT=9 
FACTLKPD=8= VPDQFACT 
END- DATA 


/  TIED  TO  MQTR  (QUARTER  NUMBER)  / 

/  LINK  TO  MQTR  (MASTER  QUARTER  FILE)  / 
/  FACULTY  SSSN  / 

/  LINK  TO  FACULTY  FSSN  / 


TOTAL-LOGICAL- RECORDS=5000 
LOG I CAL- RECORD- LENGTH=  3  0 
LOGICAL- RECORDS- PER-BLOCK= 17 
DEVICE=RA8 I 
DRIVE=  48 , 5000, DU3 

END- VARIABLE-ENTRY- DATA-SET 
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VARIABLE  SEQUENCE  FILE 


3EGIN- VARIABLE-ENTRY- DATA-SET 
DATA-SET- NAME= VMS S 
IOAREA= VAR5 


/  VARIABLE  SEQUENCE  FILE  / 


BASE-DATA 

VMSSMSSF=3 

MSSFLKSS=8=VMSSMSSF 

VMSSNMBR=  8 

MCRSLKSS=8=VMSSNMBR 

VMSSMDEG=2 

MDEGLKSS=8=VMSSMDEG 

VMSSCRSS=30 

END-DATA 


/  TIED  TO  MASTER  COURSE  SEQUENCE  NUMBER  / 

/  LINK  TO  MASTER  COURSE  SEQUENCE  FILE  / 

/  TIED  TO  MASTER  COURSE  NUMBER  / 

/.  LINK  TO  MASTER  COURSE  / 

/  TIED  TO  MASTER  DEG  REQUIREMENT  NUMBER  / 

/  LINK  TO  MASTER  DEGREE  / 

/  LISTS  WHICH  COURSES  BELONG  IN  SEQUENCE  / 


TOTAL- LOG I CAL- RECORDS=  5000 
LOG ICAL- RECORD- LENGTH=  86 
LOG I CAL- RECORDS- PER- BLOCK=  6 
DEVICE=RA81 
DRIVE=49 , 5000 »  DU 3 

END- VARIABLE-ENTRY- DATA-SET 
END- DATA-BASE-GENERATION 
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FILE/DATA  ITEM  SYNTAX  AND  COMPATIBILITY  RULES 
The  following  lists  of  data  names  represents  all  of  the  items  contained 
in  the  database  generation  source  file.  The  first  colomn  is  the  named  data 
item.  The  second  column  is  the  description  of  the  data  item.  The  third 
column  is  the  syntax  of  the  data  item  and  specifies  if  the  item  is  numeric, 
alphabetic,  and  the  format  of  the  data  item.  The  last  column  specifies  if  the 
data  item  has  any  compatibility  rules  to  be  applied.  This  appendix  is  used  in 
the  development  of  error  routines. 


-MASTER  FACULTY  FILE- 


1*'* 

NAME 

DESCRIPTION 

SYNTAX 

£ 

1  til  ■ 

FACTCRTL 

SSAN 

ALL  NUMERIC  0-9 

V* 

FACTLKSE 

LINK  TO  SECTION 

N/A 

i 

FACTLiCCM 

LINK  TO  DEPT/ COMM 

N/A 

1 

FACTNAME 

FACULTY  NAME 

ALPHBETIC 

o 

FACTRAWX 

FACULTY  RANK 

E1..E9, 

01. .010, 

G1..G13 

fla 

FACTSRVC 

MILITARY  SERVICE 

NUMERIC 

FACTDOCM 

DATE  OF  COMM IS  ION 

DDMMYY 

FACTHDAT 

DATE  HIRED 

DDMMYY 

o 

FACTSALR 

SALARY 

NUMERIC 

SS 

FACTDOBI 

DATE  OF  BIRTH 

ODMMYY 

FACTSEXX 

FACULTY  GENDER 

”M”  OR  "F” 

FACTAERO 

AERO  RATING 

ALPHA  NUMERIC 

a 

FACTDTSC 

DUTY  AFSC 

EX:  4935B 

38 

FACTPMSC 

PRIMARY  AFSC 

EX:  4935B 

F  V 

FACTDORK 

DATE  OF  RANK 

DDMMYY 

FACTYRSS 

YEARS  OF  SERVICE 

NUMERIC 

[//• 

FACTADOR 

CURRENT  ADDRESS 

ALPHA  NUMERIC 

FACTHPHN 

HOME  PHONE 

NUMERIC 

FACTEADR 

EMERGENCY  ADDRESS 

ALPHA  NUMERIC 

r'(T 

FAC  l’MSTA 

MARITAL  STATUS 

"M"  OR  ”S” 

LrT: 

FACTSPOS 

SPOUSES'  NAME 

ALPHABETIC 

fv> 

FACTSDOB 

SPOUSE  DATE  OF 

DDMMYY 

COMPATIBILITY  RULES 


SECTION  MUST  EXIST  IN 
MASTER  SECTION  FILE. 
DEPARTMENT  CODE  MUST 
EXIST  IN  MASTER  DEP. 
FILE. 

SEE  NOTE  H 


IN  YEARS 
OFFICER  ONLY 

ROUND  TO  NEAREST  DOLLAR 


MILITARY  ONLY 
MILITARY  ONLY 

ROUND  TO  NEAREST  YEAR 

DOES  NOT  INCLUDE  AREA 
CODE 


FACTNDEP 

NUMBER  OF  DEPEND. 

NUMERIC 

FACTRACE 

RACE 

ALPHABETIC 

FACTS ELN 

RELIGION 

ALPHABETIC 

FACTOFIC 

OFFICE  RM  NUMBER 

ALPHANUMERIC 

FACTOPHN 

OFFICE  PHONE  NO. 

NUMERIC 

FACTLORG 

LAST  ORGANIZATION 

ALPHANUMERIC 

FACTTITL 

LAST  DUTY  TITLE 

ALPHANUMERIC 

FACTDEPT 

DEPARTURE  DATE 

DDMMYY 

NOTE  // 1 : 

EXAMPLE  OF  CORRECT  FORMAT 

:  SMITH  JOHN 

EXCHANGE/EXTENSION 


SWW5W 


«w  ». 


MASTER  DEPARTMENT  FILE' 


NAME 

DESCRIPTION 

SYNTAX 

COMPATIBILITY  RULES 

DEPTCTRL 

DEPARTMENT  CODE 

ALPHABETIC 

DEPTNAME 

DEPARTMENT  NAME 

ALPHABETIC 

MASTER  STUDENT  FILE' 


NAME 

DESCRIPTION 

SYNTAX 

COMPATIBILITY  RULES 

STDTCTRL 

STUDENT  SSAN 

NUMERIC 

STDTLKSE 

SECTION 

N/A 

DECLARED  SECTION  MUST  EXIST 
IN  MASTER  SECTION  FILE. 

S  TDTLKAD 

LINK  TO  FACULTY 
ADVISOR 

N/A 

FACULTY  MEMBER  MUST  EXIST  IN 
MASTER  FACULTY  FILE. 

STDTSEQN 

SEQUENCE  CONTROL 

NUMERIC 

SEQUENCE  MUST  EXIST  IN 

MASTER  SEQUENCE  FILE. 

STDTNAME 

STUDENT  NAME 

ALPHANUMERIC 

STD  TRANK 

STUDENT  RANK 

E1..E9 

01. .010 
G1..G16 

STDTGRAD 

GRADUATE  OF  AFIT? 

"Y”  OR  "NM 

STDTSRVC 

MILITARY  SERVICE 

NUMERIC 

ROUND  TO  NEAREST  YEAR 

STDTAERO 

AERO  RATING 

ALPHANUMERIC 

S  TDTDORK 

DATE  OF  RANK 

DDMMYY 

STDTDOCM 

DATE  OF  COMMISSION 

DDMMYY 

MILITARY  ONLY 

STDTYRSS 

YEARS  OF  SERVICE 

NUMERIC 

ROUNT  TO  NEAREST  YEAR 

STDTSEXX 

STUDENT  GENDER 

”M"  OR  "F" 

STDTBOXN 

STUDENT  BOX  NUMBER 

NUMERIC 

STDTDTSC 

DUTY  AFSC 

EX:  4935B 

MILITARY  ONLY 

STDTPMSC 

PRIMARY  AFSC 

EX:  4935B 

MILITARY  ONLY 

3TDTADDR 

CURRENT  ADDRESS 

ALPHANUMERIC 

STREET/CITY/STATE  ETC.. 

STDTEADR 

EMERGENCY  ADDRESS 

ALPHANUMERIC 

STREET/CITY/STATE  ETC.. 

STDTHMPH 

HOME  PHONE  NUMBER 

NUMERIC 

STDTDTPH 

DUTY  PHONE  NUMBER 

NUMERIC 

STDTEDCO 

EDUCATION  CODE 

ALPHANUMERIC 

STDTDOBH 

DATE  OF  BIRTH 

DDMMYY 

STDTPOBH 

PLACE  OF  BIRTH 

ALPHANUMERIC/ ADDRESS 

STDTMSTA 

MARITAL  STATUS 

"M"  OR  "S” 

STDTSPOS 

SPOUSES'  FIRST  NAME 

ALPHABETIC 

5TDTSDOB 

SPOUSES'  DATE  OF 
BIRTH 

DDMMYY 

STDTMSPS 

MILITARY  SPOUSE 

"Y”  OR  "N" 

5TDTNDEP 

NO.  OF  DEPENDENTS 

NUMERIC 

STDTRACE 

STUDENT  RACE 

ALPHABETIC 

STDTRELN 

STUDENTS  RELIGION 

ALPHABETIC 

S  TDTLCMD 

LOSING  COMMAND 

ALPHABETIC 

f AC, SAC, MAC,  ETC.. 

S  TDTLORG 

LAST  ORGANIZATION 

ALPHANUMERIC 

STDTTITL 

LAST  DUTY  TITLE 

ALPHABETIC 

STDDIRN 

DURATION  OF  LAST 
DUTY  ASSIGNMENT 

NUMERIC 

ROUND  TO  NEAREST  YEAR 

MASTER  THESIS  CATALOG  XUMBER  FILE' 


NAME 

DESCRIPTION 

SYNTAX  COMPATIBILITY  RULES 

AONRCTRL 

THESIS  CODE 

ALPHANUMERIC 

ADNRLKTH 

LINK  TO  THESIS 

N/A 

TITLE 

MASTER  THESIS  NUMBER  FILE 


NAME 

DESCRIPTION 

SYNTAX 

COMPATIBILITY  RULES 

THESCTRL 

THESLKTA 

THESLKTC 

THESIS  CATALOG  NO. 
LINK  TO  THESIS 
ADVISOR  FILE 

LINK  TO  THESIS 
COMMITTEE  MEMBER 

NUMERIC 

N/A 

N/A 

ADVISOR  MUST  EXIST  IN  THE 
FACULTY  MASTER  FILE. 
COMMITTEE  MEMBER  MUST 
EXIST  IN  FACULTY  FILE 

MASTER  SECTION  NUMBER  FILE' 


NAME 

DESCRIPTION 

SYNTAX 

COMPATIBILITY  RULES 

SECTCTRL 

SECTION  NUMBER 

ALPHA-NUMBERIC 

STUDENT  MUST  EXIST 
STUDENT  MASTER  FILE 

SECTLKSE 

LINK  TO  SECTION 
LEADER 

N/A 

SECTLKAD 

LINK  TO  FACT 

ADVISOR 

N/A 

FACULTY  ADVISOR  MUST 
EXIST  IN  FACULTY  MASTER 
FILE 

SECTLSSN 

SECTION  LEADER 

SSAN 

NUMERIC 

SSAN  MUST  BE  IN  STUDENT 
STUDENT  MASTER  FILE. 

SECTGRDT 

GRADUATION  DATE 

DDMMYY 

SECTENDT 

ENTRY  DATE 

DDMMYY 

SECTNRSN 

NUMBER  OF  STUDENTS 

NUMERIC 

B-4 


V  OK. 


MASTER  COURSE  FILE' 


NAME 

DESCRIPTION 

SYNTAX 

COMPATIBILITY  RULES 

MCRSCTRL 

COURSE  NUMBER 

ALPHANUMERIC 

MCRSCRHR 

CREDIT  HOURS 

NUMERIC 

MCRSLCHR 

LECTURE  HOURS 

NUMERIC 

MCRSSZLM 

SIZE  LIMITATION 

NUMERIC 

DEFAULT  TO  30. 

MCRSTITL 

COURSE  TITLE 

ALPHANUMBERIC 

MCRSREST 

RESTRICTED 

”Y"  OR 

- MASTER  QUARTER  FILE - 

NAME  DESCRIPTION  SYNTAX  COMPATIBILITY  RULES 


MQTRCTRL  QUARTER  NUMBER  TWO  ALHA  SEASON 

TWO  DIGIT  YEAR 

MQTRSTDT  START  DATE  DDMMYY 

MQTRSPDT  STOP  DATE  DDMMYY 

- MASTER  BOOK  FILE - 


NAME 

DESCRIPTION 

SYNTAX 

COMPATIBILITY  RULES 

MBKTCTRL 

BOOK  TITLE  (KEY) 

ALPHANUMERIC 

MBKTLKBK 

LINK  TO  COURSE 

N/A 

COURSE  MUST  EXIST  IN 

MASTER  COURSE  FILE 

MBKTATHR 

BOOK  AUTHOR 

ALPHABETIC 

MBKTPUBL 

nOOK  PUBLISHER 

ALPHANUMERIC 

MBKTNABL 

NUMBER  AVAIL 

NUMERIC 

MBKTPRCE 

PRICE 

NUMERIC 

LAST  TWO  DIGITS  DECIMAL 

MASTER  ORDER  FILE' 


NAME 

DESCRIPTION 

SYNTAX 

COMPATIBILITY  RULES 

MORDCTRL 

MASTER  ORDER 

NUMBER  NUMERIC 

MORDORDT 

ORDER  NUMBER 

NUMERIC 

MORDDUDT 

DUE  DATE 

ODMMYY 

MORDCMPY 

COMPANY 

ALPHANUMERIC 

’10RDADDR 

ADDRESS 

ALPHANUMERIC 

MORDPHNE 

PHONE 

NUMERIC 

WITH  AREA  CODE 

MASTER  CLASS  TIME  FILE 


NAME 

DESCRIPTION 

SYNTAX 

COMPATIBILITY  RULES 

TIMECTRL 

CLASS  TIME 

NUMERIC 

MILITARY  CLOCK  0000-2400 

- MASTER  BUILDING/ROOM  FILE - 

NAME  DESCRIPTION  SYNTAX  COMPATIBILITY  RULES 


BLRMCTRL  BUILDING  AND  ROOM  NUMERIC 

NUMBER 

- MASTER  ROOM  CAPACITY  FILE - 

NAME  DESCRIPTION  SYNTAX  COMPATIBILITY  RULES 


CPIYCTRL  CAPACITY  NUMBER  NUMERIC  DEFAULT  IS  30 

CPTYLKCL  LINK  TO  CLASSROOM  N/A  ROOM  MUST  EXIST  IN 

FILE  MASTER  BUILDING/ROOM  FILE 

- MASTER  DAY  SCHEDULING  FILE - 

NAME  DESCRIPTION  SYNTAX  COMPATIBILITY  RULES 


DAYSCTRL  DAY  OF  THE  WEEK  MOND , TUES , WEDN , 

THUR.FRID 

- MASTER  SEQUENCE  FILE - 

NAME  DESCRIPTION  SYNTAX  COMPATIBILITY  RULES 


MSSFCi’RL  COURSE  SEQUENCE  NUMERIC 

NUMBER 

SEQUENCE  NAME 


MSSFSEQN 


ALPHANUMERIC 


MASTER  DEGREE  REQUIREMENTS  FILE 


NAME 

DESCRIPTION 

SYNTAX 

COMPATIBILITY  RULES 

MDEGCTRL 

GRADUATE  DEGREE 

NUMERIC 

CODE 

MDEGNAME 

DEGREE  NAME 

ALPHANUMERIC 

VARIABLE  EDUCATION  FILE' 


NAME 

DESCRIPTION 

SYNTAX 

COMPATIBILITY  RULES 

VEDUFSSN 

FACULTY  SSAN 

NUMERIC 

MUST  HAVE  AN  ASSOCIATED 
MASTER  RECORD 

VEDUSTDT 

STUDENT  SSAN 

NUMERIC 

MUST  HAVE  AN  ASSOCIATED 
MASTER  RECORD 

VEDUUNIV 

UNIVERSITY  ATT. 

ALPHABETIC 

VEDUDEGR 

DEGREE  EARNED 

ALPHABETIC 

VEDUYEAR 

YEAR  EARNED 

NUMERIC 

19XX 

FSOCFSSN 

FSOCSOCY 


•VARIABLE  FACULTY  SOCIETY  FILE- 


DESCRIPTION 


FACUTLY  SSAN 


SYNTAX 


NUMERIC 


COMPATIBILITY  RULES 


MUST  HAVE  ASSOCIATED 
MASTER  RECORD 


SOCIETIES  TO  WHICH  ALPHANUMERIC 
PERSON  BELONGS 


-VARIABLE  FACULTY  DEPT  &  COMMUTE  FILE- 


NAME 

DESCRIPTION 

SYNTAX 

COMPATIBILITY  RULES 

FCMTFSSN 

FACULrY  SSAN 

NUMERIC 

MUST  HAVE  ASSOCIATED 

FCMTDCOD 

DEPARTMENT  CODE 

NUMERIC 

MASTER  RECORD 

MUST  HAVE  ASSOCIATED 

FCMTNAMD 

FCMTDEPD 

FCMTNAMC 

FCMTNAMC 

NAME  OF  COMMITTEE 
NAME  OF  DEPARTMENT 
NAME  OF  COMMITTEE 
NAME  OF  DEPARTMENT 

ALPHABETIC 

ALPHABETIC 

ALPHABETIC 

ALPHABETIC 

MASTER  RECORD 

-VARIABLE  HONORS  AND  AWARDS  FILE- 


DESCRIPTION 


SYNTAX 


COMPATIBILITY  RULES 


VHAWFSSN 

FACULTY  SSAN 

NUMERIC 

MUST  HAVE  ASSOCIATED 
MASTER  RECORD 

VHAWSTDT 

STUDENT  SSAN 

NUMERIC 

MUST  HAVE  ASSOCIATED 
MASTER  RECORD 

VHAWNONX 

HONORS  RECIEVED 

ALPHANUMERIC 

VHAWDATE 

DATE  RECIEVED 

ODMMYY 

VHAWAWED 

AWARDS  RECIEVED 

ALPHANUMERIC 

VHAWADAT 

DATE  RECIE/ED 

DDMMYY 

-VARIABLE  FACULTY  INTEREST? 


NAME 

DESCRIPTION 

SYNTAX 

FINTFSSN 

FACULTY  SSAN 

NUMERIC 

FINTAREA 

AREA  OF  INTEREST 

ALPHANUMERIC 

- VARIABLE 

FACULTY  PUBS  AND 

NAME 

DESCRIPTION 

SYNTAX 

FCOMFSSN 

FACULTY  SSAN 

NUMERIC 

FCOMNAME 

TITLE  OF  PUB 

ALPHANUMERIC 

FCONDATE 

DATE  OF  PUB 

DDMMYY 

FCOMCOAU 

NAMES  OF 

ALPHABETIC 

CO-AUTHORS 

FCOMORGN 

PRESENTATION  GIVEN 

ALPHANUMERIC 

AT  THIS  ORGAN. 

FCOMPDAT 

DATE  PRESENTAION 

DDMMYY 

GIVEN 

FACULTY  TDY  FILE- 

NAME 

DESCRIPTION 

SYNTAX 

FTDYFSSN 

FACUTLY  SSAN 

NUMERIC 

FTDYCOST 

COST  OF  TDY 

NUMERIC 

FILE - 

COMPATIBILITY  RULES 


MUST  HAVE  ASSOCIATED 
MASTER  RECORD. 


PRESENTATIONS - 

COMPATIBILITY  RULES 

MUST  HAVE  AN  ASSOCIATED 
MASTER  RECORD 


COMPATIBILITY  RULES 


MUST  HAVE  AN  ASSOCIATED 
MASTER  RECORD 
LAST  TWO  PLACES  REP. 
CENTS 


FTDYDEST 

FTDYBDAf 

FTDYEDAT 


DESTINATION 
BEGINNING  DATE 
ENDING  DATE 


ALPHABETIC 

DDMMYY 

DDMMYY 


VARIABLE  STUDENT  COURSE  FILE- 


NAME 

DESCRIPTION 

SYNTAX 

COMPATIBILITY  RULES 

CRSESTDf 

STUDENT  SSAN 

NUMERIC 

MUST  HAVE  AN  ASSOCIATED 
MASTER  RECORD 

CRSEMDEG 

TYPE  DEGREE 

ALPHABETIC 

MUST  HAVE  AN  ASSOCIATED 
MASTER  RECORD 

CRSENUMB 

COURSE  NUMBER 

MUST  BE  CONTAINED  IN  THE 
MASTER  COURSE  FILE 

CRSENAME 

COURSE  NAME 

ALPLHABETIC 

CRSEGRAD 

COURSE  GRAD 

DDMMYY 

CRSEBEGN 

QUARTER  BEGAN 

— 

MUST  EXIST  IN  THE  MASTER 
QUARTER  FILE 

CRSECOLL 

COLLEGE  ATTENDED 

ALPHABETIC 

CRSEWAIV 

COURSE  WAIVED 

"Y"  OR  "N" 

VARIABLE  THESIS  TITLE  FILE 


NAME 

DESCRIPTION 

SYNTAX 

COMPATIBILITY  RULES 

THTLADNR 

THESIS  CATALOG  NO 

NUMERIC 

MUST  HAVE  AN  ASSOCIATED 
MASTER  RECORD 

THTLTHES 

DEPARTMENT  THES  NO 

NUMERIC 

MUST  HAVE  AN  ASSOCIATED 
MASTER  RECORD 

THTLFACT 

FACYLTY  ADVISORS 
SSAN 

NUMERIC 

MUST  HAVE  AN  ASSOCIATED 
MASTER  RECORD 

THTLSTDT 

STUDENTS  SSAN 

NUMERIC 

MUST  HAVE  AN  ASSOCIATED 
MASTER  RECORD 

THTLTITL 

THESIS  TITLE 

ALPHANUMERIC 

THTLSPON 

SPONSOR 

ALPHANUMERIC 

TUTLLOCN 

THESIS  LOCATION 

ALPHANUMERIC 

THTLCLAS 

THESIS 

"SECRET”, "TOP- 

SECRET",  ETC... 

CLASSIFICATION 

- VARIABLE  SECTION  LEADER  FILE - 

NAME  DESCRIPTION  SYNTAX  COMPATIBILI TY  RULES 


SECLSECT 

SECTION 

NUMBER 

ALPHANUMERIC 

MUST  HAVE  ASSOCIATED 
MASTER  RECORD 

SECLSTDT 

SECTION 

SSAN 

LEADER 

NUMERIC 

MUST  HAVE  ASSOCIATED 
MASTER  RECORD 

SECLFACT 

FACULTY 

SSAN 

ADVISOR 

NUMERIC 

MUST  HAVE  ASSOCIATED 
MASTER  RECORD 

VARIABLE  QUARTER  FILE' 


$ 


■s-s 


lv;-, 

ley;* 


A' 

.>»: 

‘s#; 


I  *  «  • 

*  ,V 


NAME 


VC3KNMBR 

VCBKTITL 


i 

NAME 

DESCRIPTION 

SYNTAX 

COMPATIBILITY  RULES 

m 

VCQRNMBR 

COURSE  NUMBER 

ALPHANUMERIC 

MUST  HAVE  ASSOCIATED 

* v  *•  * 

MASTER  RECORD 

v\v. 

VCQRIDEN 

QUARTER  NUMBER 

ALPHANUMERIC 

MUST  HAVE  ASSOCIATED 

m 

VCQRSSSN 

STUDENT  SSAN 

NUMERIC 

MASTER  RECORD 

MUST  HAVE  ASSOCIATED 

MASTER  RECORD 

>-v- 

VCQRGRAD 

GRADUATE  DATA 

ALPHANUMERIC 

VCQRFSSN 

FACULTY  SSAN 

NUMERIC 

MUST  HAVE  ASSOCIATED 

hV* 

MASTER  RECORD 

-VARIABLE  REQUISITE  FILE- 


iM 

»  mss 

NAME 

DESCRIPTION 

SYNTAX 

COMPATIBILITY  RULES 

W* 

*<-y, 

■  m  J  4 

VREQCODE 

CODED  RECORD  NUMBER 

NUMERIC 

VREQNMBR 

COURSE  NUMBER 

ALPHANUMERIC 

MUST  HAVE  ASSOCIATED 

• 

r  v  'r~~% 

MASTER  RECORD 

VREQRNUM 

PRE-REQUISITE 

NUMERIC 

MUST  HAVE  ASSOCIATED 

COURSE  NUMBER 

MASTER  RECORD 

r:  •*. 

VREQPNUM 

PRE-REQUISITE 

NUMERIC 

MUST  HAVE  ASSOCIATED 

V 

COURSE  NUMBER 

MASTER  RECORD 

- VARIABLE  BOOK  LINK  FILE- 

DESCRIPTION  SYNTAX 


COMPATIBILITY  RULES 


COURSE  NUMBER 
BOOK  TITLE 


NUMERIC 

ALPHANUMERIC 


MUST  HAVE  ASSOCIATED 
MASTER  RECORD 
MUST  HAVE  ASSOCIATED 
MASTER  RECORD 


-VARIABLE  NUMBER  ORDERED  FILE- 


NAME 

DESCRIPTION 

SYNTAX 

COMPATIBILITY  RULES 

$ 

VNMOTITL 

BOOK  TITLE 

ALPHANUMERIC 

MUST  HAVE  ASSOCIATED 

MASTER  RECORD 

/fv>’ 

VNMONMBR 

ORDER  NUMBER 

NUMERIC 

MUST  HAVE  ASSOCIATED 

9- 

MASTER  RECORD 

VNMONORD 

NUMBER  ORDERED 

NUMERIC 

B-II 


VARIABLE  CLASS  SCHEDULE  FILE' 


NAME 

DESCRIPTION 

SYNTAX 

COMPATIBILITY  RULES 

SCHDNSTD 

SCHDNMBR 

NUMBER  OF  STUDENTS 
COURSE  NUMBER 

NUMERIC 

ALPHANUMERIC 

MUST  HAVE  ASSOCIATED 

SCHDDAYS 

DAY  CLASS  MEETS 

ALPHABETIC 

MASTER  RECORD 

MUST  HAVE  ASSOCIATED 

SCHDTIME 

TIME  CLASS  MEETS 

NUMERIC 

MASTER  RECORD 

MUST  HAVE  ASSOCIATED 

SCHDBLRM 

BUILDING/ROOM 

NUMERIC 

MASTER  RECORD 

MUST  HAVE  ASSOCIATED 

SCHDFNTM 

FINISH  TIME 

NUMERIC 

MASTER  RECORD 

24  HOUR  CLOCK. 

VARIABLE  CLASSROOM  FILE¬ 


NAME  DESCRIPTION  SYNTAX  COMPATIBILITY  RULES 


CLSRBLRM  BUILDING  AND  ROOM  NUMERIC  MUST  HAVE  ASSOCIATED 

MASTER  RECORD 

CLSRCPTY  CAPACITY  NUMERIC  MUST  HAVE  ASSOCIATED 

MASTER  RECORD 

CLSREQPT  TYPE  OF  EQUIPEMENT  ALPHANUMERIC 

CLSRTYPE  CODE  TYPE  FOR  ALPHANUMERIC 

ROOM 

CLSRCFLG  SECURITY  LEVEL  ALPHANUMERIC 

- VARIABLE  FACULTY  ADVISOR  FILE - 


NAME 

DESCRIPTION 

SYNTAX 

COMPATIBILITY  RULES 

FADVSECT 

SECTION 

ALPHANUMERIC 

MUST  HAVE  ASSOCIATED 
MASTER  RECORD 

FADvsror 

STUDENT  SSAN 

NUMERIC 

MUST  HAVE  ASSOCIATED 
MASTER  RECORD 

FADVFACT 

FACULTY  SSAN 

NUMERIC 

MUST  HAVE  ASSOCIATED 
MASTER  RECORD 

VARIABLE  INSTRUCTOR  STATISTICS  FILE 


NAME 

DESCRIPTION 

SYNTAX 

COMPATIBILITY  RULES 

VINSSTDT 

STUDENTS  SSAN 

NUMERIC 

MUST  HAVE  ASSOCIATED 
MASTER  RECORD 

V INSNMBR 

COURSE  NUMBER 

ALPHANUMERIC 

MUST  HAVE  ASSOCIATED 
MASTER  RECORD 

VINSFACT 

FACUTLY  SSAN 

NUMERIC 

MUST  HAVE  ASSOCIATED 
MASTER  RECORD 

VARIABLE  PROFESSIONAL  DEVELOPMENT  FILE 


NAME 

DESCRIPTION 

SYNTAX 

VPDQMQTR 

QUARTER  NUMBER 

ALPHANUMERIC 

VPDQFACT 

FACULTY  SSAN 

NUMERIC 

CG'ntTPMr'C  FT T  F— 

oLyULLivC*  r  ILL 

NAME 

DESCRIPTION 

SYNTAX 

VMSSMSSF 

COURSE  SEQUENCE 

NUMERIC 

NUMBER 

7MSSNMBR 

COURSE  NUMBER 

ALPHANUMERIC 

VMSSMDEG 

DEGREE  NUMBER 

ALPHANUMERIC 

VMSSCRSS 

COURSES  IN 

ALPHANUMERIC 

SEQUENCE 

COMPATIBILITY  RULES 


MUST  HAVE  ASSOCIATED 
MASTER  RECORD 
MUST  HAVE  ASSOCIATED 
MASTER  RECORD 


COMPATIBILITY  RULES 


MUST  HAVE  ASSOCIATED 
MASTER  RECORD 
MUST  HAVE  ASSOCIATED 
MASTER  RECORD 
MUST  HAVE  ASSOCIATED 
MASTER  RECORD 


B-I3 


STANDARD  database  record  type  declarations 
'"ho  Pascal  constant  and  typo  declarations  described  in  thi 
appendix  were  used  in  the  development  of  the  AFIT/ENG  Database 
application  programs.  The  file  is  named  TYPE. PAS  and  is 
maintained  seperately  from  the  applications  programs.  The  file 
was  intended  to  be  used  as  a  #INCLUDE  file  so  maintenance  could 
be  performed  on  the  file  without  the  need  to  recompile  the 
software. 

Included  in  this  file  are  the  constants,  buffer  types, 

records  types,  and  array  types  needed  for  the  standard  database 

routines.  This  file  is  required  whenever  the  standard  routines 

are  used  within  a  program. 

CONST 

EXTRA 1  =  •  •  ; 

EXTRA 2  =  ’ 

EXTRA 3  =  ’  ’  ; 

EXTRA4  ='  '  ; 

EXTRA 5  =  ' 

EXTRA 10  =  '  '  ; 

EXTRA25  =  ’ 

EXTRA 40  =  ' 

FACTC0NST1  =  ’  FACTCTRLFACTN AI1EFACTRANK FACTS  RVCF ACTDOCM  ' 
FACTC0NST2  =  ' FACTHDATFACTSALRFACTDOB I FACTS  E  X  XFACTAERO ' 
FACTC0NST3  =  ' F  ACTDT3C  F  AC  TPMSCFACTDCRK  FACT'S  RSS FACTA DDR ' 
FACTC0NST4  =  '  FACTHPIINFACTEADRFACT.MSTAFACTSPOSFACTSDOB ' 
FACTCOMST5  =  ' FACTNDEPFACTRACEFACTRELNFACTOFICFACTOPHN ' 
FACTC0NST6  =  ' FACTLORGFACTTITLFACTDEPTEND.  ' 

STDTCCN5T1  =  ' STDTCTRLSTDTSEQNSTDTNAMS5TDTRAMKSTDTG RAD ' 
STDTC0NST2  =  ’ STDTSRVCSTDTAEROSTDTDCRKSTDTDOCriSTDTYRSS ' 
STDTC0NST3  =  ' STDTSEXXSTDTD0XN5TDTDTSCSTDTPMSCSTDTADDR ' 
STDTCONST4  =  '  STDTEADRSTDTHMP'ISTDTDTPHSTDTEDCDSTDTDOBH  ' 
STDTC0NST5  =  ' STDTP0BHSTDTMSTA5TDTSPCSSTDTSD0BSTDTMSPS ' 
STDTC0NST6  =  ' STDTNDEPSTDTRACESTDTRELNSTDTLCHDSTDTLORG ' 
STDTCONST7  =  ' STDTTITLSTDTDURNEND . 

DEPTCONST1  =  ' DEPTCTRLDEPTNAMEEND. 

THESCONST1  =  '  THE3CTRLTHESTITLTHESSP0NTIIESL0CNTHESCLAS  ’ 
THESC0NST2  =  ' THESNAMEEND.  ' 

SECTC0NST1  =  ' SECTCTRLSECTLSSNSECTGRDTSECTENDTSECTNRSN ' 
SECTCONST2  =  'END. 

MCRSC0NST1  =  '  MCRSCTRLMCRSCRIIRMCRSLCHRMCRSLBHRMCRSSZLM  ' 
MCRSC0NST2  =  ' MCRST ITLMCRS RESTEND .  ' 

MQTRCONST1  =  ' MQTRCTRLMQTRSTDTMQTRSPDTEND . 


MBK7C0NST1  =  '  MBK7CTRLMBK7ATHRMBK7PUBL:‘3KTNAVLMBK7PRCE 
MBK7CONST2  =  ' END. 

MORDCONST1  =  ' M0RDC7RLM0RD0RDTM0RDDCJD7K0RDCMPYM0RDADDR 
MORDCONST2  =  ' MORDPHNEEND. 

TIMECONST1  =  ' 7IMECTRLEND. 

3LRMC0NS71  =  ' BLRMC7RLEND . 

CPTYCONST1  =  ' CPTYCTRLEND . 

DAYSCONST1  =  ' DAYSCTRLEND. 

MSSFCONST1  =  ' MSSFCTRLMSSFSEQHEMD . 

MDEGCONST1  =  ' MDEGCTRLMDEGNAMEEND. 

VEDUCONST1  =  ' VEDUFSSNVEDUSTD7VEDUUN I VVEDUDEGRVEDUYEAR 
VEDUCONST2  =  'END. 

FSOCCONST1  =  ' FSOCFSSNFSOCSOCYFSOCDUM1END. 

FCMTCONST1  =  ' FCMTC0DEFCMTFSSNFCM7DC0DFCMTDA7AFCM7NAMD 
FCM7C0NS72  =  ' FCMTDEPDFCMTNAMCFCHTDEPCEND . 

VIIAWCONSTl  =  '  VI1AWCODEVHAWFSS NVHAWSTDTVHAWDATAVHAWIIONR 
VHAWCONST2  =  '  VIIAWDA7EVHAWANRDVHAWADA7END . 

FINTCONST1  =  ' FINTFSSNFINTAREAEND. 

FCOf ICONST1  =  '  FCOMCODEFCOMFSSNFCOHDATAFCOMNAMEFCOtiDATE 
FC0MC0NS72  =  ' FCOMCOQUFCOMORGNFCOMPDATEMD. 

F7DYC0NS71  =  ' F7DYFSSNF7DYCOS7FTDYDESTF7DYBDA7F7DYEDA7 
F7DYCONS72  =  '  E?” 

CRSECONST1  =  'CR^STDTCRSEMDEGCRSENUMBCRSEHAMECRSEGRAD 
CRSECONST2  =  ’ CRSEBEGNCRSECOLLCRSEWAI VEND. 

THTLCONS71  =  '  THTLADNRTHTLTHESTHTLFACTTH7LS7DTTIITL7ITL 
7HTLCONTS2  =  '  THTL5P0NTI1TLL0CNTHTLCLASEND. 

SECLC0NS71  =  ' SECLSECTSECLSTD7SECLFACTEND. 

VCQRCONST1  =  ' VCQRCODEVCQRNMBRVCQRIDENVCQRSSSNEND. 
VCQRCONS72  =  '  *CODE=QSVCQRNMBRVCQRIDENEND. 

7REQC0NS71  =  ' VREQCODEVREQNMBRVREQDATAVREQRNUNVRE23LKA 
7REQCONST2  =  ' VREQPNUMVREQBLKBEND . 

VCBKCONST1  =  ' VCBKNM3RVCBK7I7LEND. 

7NMOCONST1  =  ' VNM07I7LVNM0NMBRVNM0N0RDEMD . 

SCNDC0NS71  =  ’  SC:iDNS7DSCHDNMBRSCIIDDAY3SC:iD7IMSSC!IDBLRM 
SCHDCONS72  =  ' SCMDFH7MEMD . 

CLSRC0NS71  =  '  CLSR3LRflCLSRCPTYCLSREQPTCL3R7YPECLSRCLFG 
CLSRCON372  =  'END. 

7CMFC0NST1  =  ’ 7CMFFAC77CMFSTDT7CMF73ESEND. 

FADVC0NS71  =  ’ FAD7S  ECTFADVS7D7FADVFAC7END . 

VINSCONST1  =  ' 7INSS7DTVINSNM3RVI NSFACTEND. 

7ADVC0NS71  =  ' 7ADV7HE3TADVS7DT7AD7FACTEND . 

VPDQCONST1  =  ' VPDQMQ7R7PDQFAC7END. 

V.MSSCONST1  =  '  VMSSMSSFVMSSNMBRVMSSMDEGVMSSCRSSEND. 
EX7RA  =  ' 


TYPE 


3UFF1 

s 

CHAR; 

3UFF2 

= 

PACKED 

ARRAY [1.. 2]  OF 

CHAR ; 

BUFF  3 

= 

PACKED 

ARRAY 

1..3]  OF 

CHAR; 

BUFF  4 

3 

PACKED 

ARRAY 

[  1. . 4]  OF  CHAR 

BUFF5 

= 

PACKED 

ARRAY 

[ 1. . 5]  OF  C 

HAR 

3UFF6 

= 

PACKED 

ARRAY 

[ 1. . 6]  OF  CHAR 

BUFF7 

3 

PACKED 

ARRAY 

[1.  .71  OF  CHAR 

BUFF8 

= 

PACKED 

ARRAY 

[  1.  .  8]  OF  CHAR 

3UFF9 

= 

PACKED 

ARRAY 

[ 1 . . 9]  OF  CHAR 

BUFF10 

= 

PACKED 

ARRAY 

[1.  .101 

OF 

CHAR; 

3UFF11 

= 

PACKED 

ARRAY 

[  1  -  .  Ill 

OF 

CHAR; 

BUFF12 

= 

PACKED 

ARRAY 

[1. .12] 

OF 

CHAR; 

3UFF14 

= 

PACKED 

ARRAY 

til .14] 

OF 

CHAR; 

BUFFI  5 

3 

PACKED 

ARRAY 

f 1. .15) 

OF 

CHAR; 

3UFF16 

3 

PACKED 

ARRAY 

[1. .16] 

OF 

CHAR; 

BUFF17 

3 

PACKED 

ARRAY 

(1. .17] 

OF 

CHAR; 

BUFF  1 8 

3 

PACKED 

ARRAY 

11. .18] 

OF 

CHAR; 

BUFF19 

3 

PACKED 

ARRAY 

[1.  .19] 

OF 

CHAR; 

BUFF20 

3 

PACKED 

ARRAY 

[ 1. . 20] 

OF 

CHAR; 

3UFF21 

3 

PACKED 

ARRAY 

11. . 21] 

OF 

CHAR; 

BUFF22  = 

PACKED 

ARRAY 

[1. .22] 

OF 

CHAR; 

BUFF23 

3 

PACKED 

ARRAY 

[1..23] 

OF 

CHAR; 

BUFF24 

3 

PACKED 

ARRAY 

[ 1. . 24] 

OF 

CHAR; 

BUFF25 

3 

PACKED 

ARRAY 

[1. .25] 

OF 

CHAR; 

BUFF28 

3 

PACKED 

ARRAY 

(1. . 28] 

OF 

CHAR; 

BUFF30 

3 

PACKED 

ARRAY 

11. .30] 

OF 

CHAR; 

BUFF  3  3 

3 

PACKED 

ARRAY 

[1.  .33] 

OF 

CHAR; 

3UFF36 

3 

PACKED 

ARRAY 

[ 1. . 36] 

OF 

CHAR; 

BUFF38 

3 

PACKED 

ARRAY 

[1. .38] 

OF 

CHAR; 

BUFF  40 

3 

PACKED 

ARRAY 

11. . 40] 

OF 

CHAR; 

BUFF 4 8 

3 

PACKED 

ARRAY 

[1. . 48] 

OF 

CHAR  ; 

BUFF  50 

= 

PACKED 

ARRAY 

[ 1. . 50] 

OF 

CHAR; 

3UFF61 

3 

PACKED 

ARRAY 

l 1. . 61) 

OF 

CIIAR; 

3UFF30 

3 

PACKED 

ARRAY 

[1. .80] 

OF 

CHAR ; 

3UFF120 

3 

PACKED 

ARRAY 

11. .120] 

OF 

CHAR 

BUFFI  22 

3 

PACKED 

ARRAY 

[1.  .122] 

OF 

CHAR 

3UFF130 

= 

PACKED 

ARRAY 

11.  .130] 

OF 

CHAR 

3UFF200 

3 

PACKED 

ARRAY 

[1. . 200] 

OF 

CIIAR 

BUFF240 

3 

PACKED 

ARRAY 

[ 1. . 240] 

OF 

CHAR 

BUFF236 

3 

PACKED 

ARRAY 

[1. .236] 

OF 

CHAR 

3UFF280 

3 

PACKED 

ARRAY 

[ 1 . . 280] 

OF 

CHAR 

BUFF  400 

= 

PACKED 

ARRAY 

[ 1. . 400] 

OF 

CIIAR 

3UFF408 

3 

PACKED 

ARRAY 

11. .408] 

OF 

CHAR 

BUFF480 

3 

PACKED 

ARRAY 

11. . 480] 

OF 

CHAR 

RECORD; 

RL  :  BUFF9 ;  {*  3SAN  *} 

ME  :  3UFF23 ; 

{*  FACULTY  MEMBERS  NAME , LAST , F I RST , MI  * } 

NIK  :  SUFF3  ; 

{*  MIL/CIV  RANK  ( O-OFFICER , G-CI V , NN-RANK ) * } 

VC  :  BUFF2 ;  {*  MILITARY  SERVICE  *} 

CM  :  BUFF 6;  {*  DATE  OF  COMMISSION  *} 

AT  ;  BUFF6 ;  {*  DATE  HIRED  *} 

LR  :  BUFFS;  {*  SALARY  *} 

B I  :  BUFF6;  {*  DATE  OF  BIRTH  *} 

XX  :  BUFFI;  {*  SEX  *} 

RO  :  BUFF10;  {*  AERO  RATING  *} 

SC  :  BUFF6;  {*  DUTY  AFSC  *} 

SC  ;  BUFF 6;  {*  PRIMARY  AFSC  *} 

RK  :  BUFF6;  {*  DATE  OF  RANK  *} 

SS  :  BUFF2 ;  {*  YEARS  OF  SERVICE  *} 

DR  ;  BUFF40 ;  {*  CURRENT  ADDRESS  -  *} 

HN  :  BUFF?  ;  {*  HOME  PHONE  ( EXCHANGE , EXTENSION) * } 

DR  ;  BUFF 4  0;  {*  EMERGENCY  ADDRESS  *} 

TA  :  BUFFI  ;  {*  MARITAL  STATUS  *} 

OS  :  BUFF12 ;  {*  SPOUSE  FIRST  NAME  *} 

OB  :  BUFF 6  ;  {*  SPOUSE  DATE  OF  BIRTH  *} 

EP  :  BUFF2  ;  {*  NUMBER  OF  DEPENDENTS  *} 

CE  :  BUFF2  ;  {*  RACE  *} 

LN  ;  BUFF2  ;  {*  RELIGION  *} 

IC  :  BUFFI 2 ;  {*  OFFICE  RM  NUMBER  *} 

HN  :  BUFF7  ;  {*  OFFICE  PHONE  (EXCHANGE, EXTENSION) * } 

RG  ;  BUFF 50;  {*  LAST  ORGANIZATION  *} 

TL  :  BUFF50 ;  {*  LAST  POSITION  TITLE  *} 

PT  :  BUFF6  ;  {*  EXPECTED  AFIT  DEPARTURE  DATE  *} 


RECORD; 

RL  :  BUFF 4  ;  {*  DEPT  CODE  *} 

ME  :  BUFF 20 


REC  =  RECORD; 


CTRL 

BUFF9 ; 

{* 

STUDENT  SOCIAL  SECURITY  *} 

SEQN 

BUFF 3  ; 

{* 

MASTER  SEQUENCE  CONTROL  NUMBER  *1 

MANE 

3UFF23 ; 

{* 

STUDENT  NAME  ( LAST , F I RST , M I )  *} 

RANK 

BUFF  3 ; 

{* 

MIL/CIV  RANK ( O-OFF ICER , G-C IV, NN-RANK  *} 

GRAD 

BUFFI ; 

{* 

HAS  STUDENT  ALREADY  GRADUATED/LEFT  AFIT 

SRVC 

BUFF2 ; 

{* 

MILITARY  SERVICE  *} 

AERO 

BUFFI  0 ; 

{* 

AERO  RATING  *} 

DORK 

BUFF 6 ; 

{* 

DATE  OF  RANK  *} 

DOCM 

BUFF 6 ; 

{* 

DATE  OF  COMMISSION  *} 

YRSS 

BUFF 2 ; 

{* 

YEARS  OF  SERVICE  *} 

SEXX 

BUFFI; 

{* 

SEX  *} 

30XN 

BUFF4 ; 

{* 

BOX  NUMBER  *} 

DTSC 

BUFF 6; 

{* 

DUTY  AFSC  *} 

PMSC 

BUFF6 ; 

{* 

PRIMARY  AFSC  *} 

ADDR 

BUFF  40 ; 

{* 

CURRENT  ADDRESS  *} 

EADR 

BUFF40 ; 

{* 

EMERGENCY  ADDRESS  *} 

HMPH 

BUFF7 ; 

{* 

HOME  PHONE  NUM3ER  *} 

DTPH 

SUFF7 ; 

DUTY  PHONE  NUMBER  *} 

EDCD 

BUFF  5; 

l* 

EDUCATION  CODE  *} 

DOBH 

BUFF 6 ; 

{* 

DATE  OF  BIRTH  *} 

P03H 

BUFF40 ; 

{* 

PLACE  OF  BIRTH  *} 

MSTA 

3UFF1 ; 

l* 

MARITAL  STATUS  -*} 

SPOS 

BUFF12 ; 

{* 

SPOUSE  FIRST  NAME  *} 

SDOB 

BUFF6 ; 

{* 

SPOUSE  DATE  OF  BIRTII  *} 

MSPS 

BUFFI ; 

{* 

MILITARY  SPOUSE  *} 

NDEP 

BUFF2 ; 

{* 

NUMBER  OF  DEPENDENTS  *} 

RACE 

BUFF2; 

{* 

RACE  *} 

RELN 

BUFF2; 

1  + 

RELIGION  *} 

LCMD 

BUFF  5; 

{* 

LOSING  COMMAND  *} 

LORG 

3UFF50 ; 

l* 

LAST  ORGANIZATION  *} 

TITL 

BUFF50 ; 

{* 

LAST  POSITION  TITLE  *} 

OURN 

3UFF2 ; 

{* 

DURATION  AT  LAST  DUTY*} 

REC  =  RECORD; 


CTRL 

BUFF10 ; 

{* 

THESIS 

CATALOGING 

NUMBER*} 

TITL 

BUFF  50 ; 

{ *  THESIS 

TITLE*} 

SPON 

BUFF  50 ; 

{* 

THESIS 

SPONSOR*} 

LOCN 

BUFF50 ; 

{* 

THESIS 

LOCATION* } 

CLAS 

BUFFI  2 ; 

{* 

THESIS 

CLASSIFICAT 

ION*} 

NAME 

BUFF28 ; 

{* 

STUDE 

NTS  NAME  FOR 

ARCHIVE 

SECT_REC  =  RECORD; 

CTRL  :  BUFFS 
LKSE  :  BUFF8 
LKAD  :  BUFFS 
LSSH  :  BUFF9 
GRDT  :  BUFF6 
ENDT  :  BUFF6 
NRSN  :  BUFF  3 

END; 


MCRS 


REC  =  RECORD; 
CTRL  :  BUFF8 


CRHR 

LCHR 

LBHR 

SZLM 

TITL 

REST 


BUFFI ; 
BUFFI ; 
BUFFI ; 
BUFF2 ; 
3UFF50 ; 
BUFFI ; 


ilQTR 


REC  =  RECORD; 
CTRL  :  BUFF4 
STDT  :  BUFF6 
SPDT  :  BUFF6 


MBKT  REC  =  RECORD; 


CTRL 

ATIIR 

PUBL 

NAVL 

PRCE 


BUFF  40 
BUFF  28 
BUFF28 
BUFF6; 
BUFF  4 ; 


REC  =  RECORD; 


CTRL 

ORDT 

DUDT 

CMPY 

ADDR 

PUNE 


BUFF7 ; 
BUFF6 ; 
3UFF6 ; 
BUFF23 ; 
BUFF43 ; 
BUFF10 ; 


TIME 


END; 


BLRM 


CPTY 


REC  =  RECORD; 

CTRL  :  BUFF  4 ; 


REC  =  RECORD; 
CTRL  :  BUFF8; 


REC  =  RECORD; 

CTRL  :  BUFF  4; 


{ *  SECTION  NUMBER  (EX.,  GCS-34D)*} 

{ *  L I NK  TO  SECTION  LEADER  FILE*} 

{ *  LINK  TO  FACULTY  ADVISOR*} 

{ *  SECTION  LEADER  SSSN*} 
{♦GRADUATION  DATE*} 

{♦ENTRY  DATE*} 

{♦NUMBER  OF  STUDENTS  IN  SECTION*} 


{♦COURSE  NUMBER*} 

{♦COURSE  CREDIT  HOURS*} 

{♦COURSE  LECTURE  HOURS  DATA*} 

{♦COURSE  LAB  HOUR  DATA*} 

{♦SIZE  LIMIT  DATA*} 

{♦TITLE  DATA*} 

{♦RESTRICTED  (FROM  GRAD  REQ)  COURSE*} 


{♦QUARTER  NUMBER*} 

{♦QUARTER  START  DATE ( DAY , MO , YR) * } 
{♦QUARTER  STOP  DATE  ( DAY , MO , YR) * } 


{♦BOOK  TITLE  NAME*} 

{♦BOOK  AUTHOR  NAME  (  LAST  ,  F IRST  ,  ill  )*  } 
{♦BOOK  PUBLISHER  NAME*} 

{♦BOOKS  AVAILABLE*} 

{♦BOOK  PRICE*} 


{♦MASTER  ORDER  NUMBER*} 

{♦ORDER  NUMBER*} 

{♦DUE  DATE*} 

{♦COMPANY* } 

{♦COMPANY  ADDRESS*} 

{ *  COMPANY  PHONE  NUMBER  WITH  AREA  CODE*; 


{♦MILITARY  CLOCK  TIME*} 


{♦BUILDING  AND  ROOM  NUMBER*; 


{♦CAPACITY  NUMBER*} 


VW* WWW 


DAYS_ 

END; 

::ssf_ 

END; 

MDEG 


REG  =  RECORD; 
CTRL  :  BUFF 4 ; 


REC  =  RECORD; 

CTRL  :  BUFF 3 ; 
SEQN  :  BUFF40 ; 


REC  =  RECORD; 

CTRL  :  BUFF2 ; 
WANE  :  BUFF  4  3; 


VEDU  REC  =  RECORD; 


FSSN 
STDT 
UN  IV 
DEGR 
YEAR 


BUFF9 ; 
BUFF9  ; 
3UFF40 ; 
BUFF  4  0 ; 
BUFF  4 ; 


FSOC_REC  =  RECORD; 

FSSN  ;  BUFF9 ; 
SOCY  :  BUFF40 ; 
DU Ml  :  BUFF 8; 

END; 


REC  =  RECORD; 


711  AW  REC  =  RECORD; 


CODE 

BUFF2 ; 

FSSN 

BUFF9 ; 

STDT 

BUFF9 ; 

DATA 

BUFF 16 ; 

HONR 

BUFF 1 3 ; 

DATE 

BUFF6 ; 

AWRD 

BUFFI  0 ; 

A  DAT 

BUFF6 ; 

END; 


{♦DAY  OF  THE  'WEEK* 


{ *  COURSE  SEQUENCE  NUM3ER*  j 
{♦SEQUENCE  NAME*} 


{♦NUMBER  IDENTIFYING  TYPE  GRAD  DEGREE*} 
{♦NAME  OF  TYPE  OF  DEGREE*} 


{♦FACULTY  SSN* } 

{♦STUDENT  SSN*} 

{♦INSTITUTION  (UNIVERSITY)  ATTENDED*} 
{♦DEGREE  EARNED*} 

{♦YEAR  DEGREE  AWARDED* } 


{♦FACULTY  SSN*} 

{♦SOCIETIES  TO  'WHICH  INDIVIDUAL  BELONGS  *} 
{♦PADDING  TO  INCREASE  REC  LENGTH*} 


CODE 

3UFF2 ; 

FSSN 

3UFF9 ; 

{♦FACULTY 

SSN  ;  BUFF9* } 

DCOD 

BUFF4 ; 

{♦DEPARTMENT  DCOD*} 

DATA 

3UFF14  ; 

{♦REDEFINED  DATA  AREA  LENG 

NAMD 

BUFF  1 0  ; 

{♦NAME  OF 

COMMITTEE*} 

DEPD 

BUFF  4; 

{♦NAME  OF 

DEPARTMENT  ??*} 

NAMC 

BUFF  10 ; 

{♦NAME  OF 

OTHER  COMMITTEE* 

DEPC 

BUFF  4 ; 

{♦NAME  OF 

OTHER  DEPARTMENT 

{♦FACULTY  SSN*} 

{♦STUDENT  SOCIAL  SECURITY  NUMBER* 
{♦REDEFINING  DATA  LENGTH  AREA*} 
{♦HONORS  RECEIVED*} 

{♦DATE  HONOR  RECEIVED*} 

{♦AWARDS  RECEIVED*} 

{♦DATE  AWARD  RECEIVED*} 


A.  ■f.w -f.  A.  -A  -  .  '.A  A  -  A 


FINT_REC  =  RECORD; 

FSSN  :  BUFFO ; 
AREA  :  BUFFI  5; 


FCOM  REC  =  RECORD; 


CODE 

BUFF2 ; 

FSSN 

BUFF9 ; 

DATA 

BUFF61 ; 

NAME 

BUFF25; 

DATE 

BUFF6 ; 

COAU 

BUFF  30; 

ORGN 

BUFF25 ; 

PDAT 

BUFF6; 

FTDY_REC  =  RECORD; 

FSSN  :  BUFFO; 
COST  :  BUFF7 ; 
DEST  :  BUFF20 ; 
BDAT  :  3UFF6 ; 
EDAT  :  BUFF6 ; 

END; 


CRSE  REC  =  RECORD; 


STDT 

BUFF9 ; 

MDEG 

3UFF2 ; 

NUMB 

BUFF8 ; 

NAME 

BUFF20 ; 

GRAD 

3UFF2 ; 

3EGN 

BUFF  4 ; 

COLL 

BUFF  30 ; 

WAIV 

BUFFI ; 

T!!TL_REC  =  RECORD; 

TIIES  :  3UFF1 3 ; 
FACT  :  BUFFO; 
STDT  :  BUFFO; 

END; 


{ *  FACULTY  SSN* } 

{ * AREA  OF  INTEREST*} 


{  *  FACULTY  SSN*  } 

{♦REDEFINED  DATA  AREA  LENGTH*} 

{♦TITLE  OF  PUBLICATION*} 

{♦DATE  OF  PUBLICATION*} 

{  *  NAME { S )  OF  CO-AUTHOR (S) *} 

{♦PRESENTATION  GIVEN  TO  THIS  ORGANIZATION*} 
{♦PRESENTATION  DATE*} 


{♦FACULTY  SSN*} 

{♦COST  OF  TDY  DATA  IN  THIS  FILE*} 
{  *  DESTINATION* } 

{*  DATE*} 

{♦END  DATA*} 


{♦STUDENT  SOCIAL  SECURITY  NUMBER*} 

{♦TYPE  GRAD  DEGREE  (NUMBER  -  FROM  MDEG) * } 
{♦COURSE  NUMBER*} 

{♦COURSE  NAME*} 

{♦COURSE  GRADE*} 

{♦QUARTER  STUDENT  TOOK  OR  WILL  TAKE  COURSE*} 
{♦COLLEGE  ATTENDED*} 

{♦COURSE  WAIVED?  (Y/N)*} 


{♦DEPARTMENT  THESIS  HUMSER* } 
{♦FACULTY  ADVISOR  FSSN*} 
{♦STUDENT  SS5N* } 


SEC"1 

BUFF8 ; 

{ *  RELATED 

TO  SECT 

(SECTION  NUMBER)* 

STDT 

BUFF9 ; 

{♦STUDENT 

SSSN* } 

FACT 

BUFF9 ; 

{ *  FACULTY 

FSSN*} 

VREC  = 


RECORD; 
CODE  : 
NMBR  : 
I  DEN  : 
SSSN  : 
VREF  : 


BUFF2 

BUFFS 

BUFF4 

BUFFO 

3UFF4 


{♦COURSE  NUMBER  CONTROL  FIELD*} 
{♦QUARTER  IDENT  CONTROL  FIELD*} 
{* STUDENT  SSN  DATA*} 


END; 


7REQ_REC  =  RECORD; 

CODE  :  BUFF  2 ; 
NMBR  :  BJFF8 ; 
DATA  :  BUFFI  2 ; 
RIJUM  :  BUFF8; 
3LKA  :  3UFF6; 
PNUM  :  BUFF8; 
BLK3  :  BUFF6; 


{ *  CODED  RECORD  FOR  REQUISITE*} 
{♦COURSE  NUMBER  CONTROL  FIELD*} 

{ *  REDEFINED  REQUISITE  DATA*} 
{♦REQUISITE  COURSE  NUMBER*} 
{♦RECORD  3TYE  FILLER  FOR  TOTAL*} 
{♦REQUISITE  COURSE  NUMBER*} 
{♦RECORD  BYTE  FILLER  FOR  TOTAL*} 


VCBK_REC  =  RECORD; 

NMBR  :  3UFF8;  {*COURSE  NUMBER  CONTROL  FIELD*} 
TITL  :  BUFF40;  {*BOOK  TITLE  CONTROL  FIELD*} 

END; 


VNMO_REC  =  RECORD; 

TITL  :  BUFF40 
NMBR  :  BUFF7 ; 
NCRD  :  3UFF3; 

END; 


{♦BOOK  TITLE  CONTROL  FIELD*} 
{♦ORDER  NUMBER  CONTROL  FIELD*} 
{♦NUMBER  ORDERED  DATA  ITEM*} 


SCUD  RE C  =  RECORD; 


NSTD 

BUFF 3  ; 

NMBR 

BUFF8 

DAYS 

BUFF  4; 

TIME 

BUFF 4  ; 

BLRM 

BUFF 8; 

FNTM 

BUFF4 ; 

END; 

CLSR  REC  =  RECORD; 


3LRM 

BUFF8 

CPTY 

BUFF  4 

EQPT 

DUFF  2 

TYPP 

3UFF3 

CFLG 

BUFFI 

{♦NUMBER  OF  STUDENTS  IN  CLASS*} 
{♦COURSE  NUMBER*} 

{♦DAY  CLASS  MEETS*} 

{♦TIME  CLASS  STARTS*} 

{ *3U ILDING  AND  ROOM  NUMBER*} 
{♦CLASS  FINISH  TIME*} 


{♦BUILDING  AND  ROOM  NUMBER*} 

{♦CAPACITY  OF  ROOM*} 

{♦TYPE (5)  OF  EQUIPMENT  IN  ROOM*} 

{♦CODE  FOR  TYPE  OF  ROOM*} 

{♦CODE  FOR  SECURITY  CLASSIFICATION  LEVEL  OF 


\EC  =  RECORD; 

FACT  :  BUFF9; 
5TDT  :  3UFF9 ; 
CUES  :  3UFF10; 


{♦FACULTY  3 S N * } 

{♦STUDENT  S3N*  } 

{♦DEPARTMENT  THESIS  NUM3ER* } 


FADV_REC  =  RECORD; 

SECT  :  BUFFO 
STDT  :  BUFF9 
FACT  ;  3UFF9 


{♦SECT  CTRL  (SEC 
{♦STUDENT  SSSN* } 
{♦FACULTY  FSSN*} 


NUMBER) * 


VI  MS  REC 


end,* 


:  =  RECORD ; 
3TDT  :  BUFF9 
NMBR  :  3UFF8 
FACT  :  BUFF9 


{* STUDENT  SSSII*} 

{ * KC RS  CTRL  (COURSI 
{* FACULTY  SSSN*} 


NUMBER) *} 


TADV_REC  =  RECORD; 

THES  :  3UFF10 ;  {* IDENTIFIES  TIED  TO  THES  NUMBER*} 

STDT  :  BUFF9 ;  { *  STUDENT  SSSN*} 

FACT  :  BUFF9 ;  {* FACULTY  FSSN*} 

END; 

VPDQ_REC  =  RECORD; 

I1QTR  :  BUFF4 ; 

FACT  :  3UFF9 ; 

END; 

VMSS_REC  =  RECORD; 

MS  S  F  :  BUFF  3; 

NMBR  :  3UFF3 ; 

MDEG  :  BUFF2 ; 

CRSS  :  3UFF33 
VREF  ;  BUFF4 ; 

END; 

MSSF_PTR  =  ~MSSF_RECORD; 

MS3F_RECORD  =  RECORD; 

CTRL  :  BUFF 3 ;  { *COURSE  SEQUENCE  NUMBER*) 

SCON  :  BUFF  4  3  ;  { *  SEQUENCE  NAME*} 

NEXT  :  MSSF_PTR; 

PREV  :  MSSF_PTR ; 

END; 

:iDZG_PTR  =  \UDSG_RECORD; 

MDEG_RECORD  =  RECORD; 

CTRL  :  BUFF 2;  {* NUMBER  IDENTIFYING  TYPE  GRAD  DEGREE*} 

NAME  :  3UFF40;  { *  NAME  OF  TYPE  OF  DEGREE*} 

i  •  i  J  JuO  r  i  i\  , 

PREV  :  MDEG~PTR; 

END ; 

L I NK_PTR  =  “ LINK_RECORD; 

L I  NK_ RECORD  =  RECORL 

NAME  :  BUFF 2 3 ; 

CTRL  :  BUFF9; 

RANK  :  BUFF  3 ; 

DEPT  :  BUFF4; 

SECT  :  BUFF3; 

NEXT  :  LINK_PTR; 

PREV  :  LINK_PTR; 

END;  {*  LINK  RECORD  *} 


} * TI ED  TO  MQTR  (QUARTER  NUMBER)*} 
j  *  FACULTY  SSSN*} 


{ *  TI ED  TO  MASTER  COURSE  SEQUENCE  NUMBER*} 
{*TIED  TO  MASTER  COURSE  NUMBER*} 

{ *TIED  TO  MASTER  DEG  REQUIREMENT  NUMBER*} 
{* LISTS  WHICH  COURSES  BELONG  IN  SEQUENCE*} 
{* RECORD  REFERENCE  *} 


{*  THESE  TYPE  DECLARATIONS  ARE  USED  IN  VARIOUS  *} 
{*  LIST  PROCESSING  THAT  IS  UNIQUE  TO  THE  EDPLAN 
{*  PROGRAM.  *} 


SECT_ARRAY 
L INK_ARRAY 
CRSE_ARRAY 
VCQR_ARRAY 
VMSS  ARRAY 


ARRAY  [ 1 . . 103 ]  OF  SECT_REC; 
ARRAY  [1..I00J  OF  LINK_RECORD ; 
ARRAY  [ 1 . . 30 )  OF  CRSE_REC; 
ARRAY  [I.. 1201  OF  VCQR_REC; 
ARRAY  (1..30]  OF  VMSS  REC; 


C-ll 


Appendix  D 


SYSTEM  FLOWCHARTS 


This  portion  contains  the  structure  charts  for  the 
anticipated  application  program  structure.  The  charts  are 
intended  to  describe  the  system  in  terms  of  a  map  that  the 
systems  analyst  and  users  can  follow  to  3  specific  function, 
first  chart  (page  D-2)  depicts  the  system  in  terms  of  the 
seperate  applications  programs.  FACTMOD,  STDTMOD,  CRSEMOD. .et 
are  seperately  compiled  programs  spawned  as  seperate  processes 
by  a  main  program.  The  standard  database  routines  have  been 
omitted  because  they  are  considered  abstractions  of  a  data 
structure  which  in  this  case  is  the  TOTAL  Database  Management 
system . 


AFIT/EN  DATABASE  SYSTEM 


FACULTY  AND  DEPARTMENT  NODULES 


DEPT. STATS  ADDDEPT  |  DELDEPT  UPTDEPT 


COURSE  DATABASE  MODULES 


EDUCATION  PLAN  MODULE  (1) 


NOTE i  THE  INDICATES  THIS  NODULE  NAICES  NO  CALLS. 

AN  *6*  INDICATES  CALLS  TO  STANDARD  DSNS  AOUTIfCS 


EDUCATION  PLAN  NODULE  (3) 


NOTE)  A  INDICATES  THIS  ROUTINE  HAKES  NO  CAU.S. 

AN  ’S*  INDICATES  ONLY  STANDARD  DSNS  CAUS  ARE  HADE 


EDUCATION  PLAN  MODULE  (4) 


Appendix  E 

AFITDB  Frames  Descriptions 

The  following  is  a  compilation  of  the  FMS  form  screens 
contained  within  the  library  which  supports  the  AFIT/ENG  D3MS. 
Each  screen  must  be  resident  within  a  library  in  order  to  require 
only  one  open  and  close  statement  within  a  program.  The  listings 
were  created  using  the  instruction  FMS/ DESCRIPT I ON/ IMAGE 
" f ormname " .  This  creates  a  file  called  formname.lis  which  can 
then  be  printed  in  the  format  described  in  this  appendix. 

The  three  column  format  is  produced  using  the  fms  form 
utility  (FUT) .  The  date  column  lists  the  latest  date  changes 
were  made  to  each  form,  while  column  three  shows  the  work  space 
area  ,  in  bytes,  reserved  for  each  screen  within  the  FMS  driver 
work  space  area. 


Form  Application  Aids  72. 2 
19- NOV- 1085  33:98 


Li  or  ary  DUA1 :  [ PANGMAN . AF ITD3 ] STDTMOD . FLB ; 1 , 
created:  12-SEP-1935  13:13 


Date  and  time 

of  last  modification:  19- 

NOV-1935  33:57 

Form  name 

Creation  date 

/time  'work 

space  size  (bytes) 

CDPLAN1 

1 9- NOV- 1935 

03  :  57 

5779 

NAMES EL 

13-SEP-1935 

11:35 

1329 

NELPEDPL 

1 8-SEP- 1 9  8  5 

13:31 

1109 

ZDPLAt! 

19-NOV-1985 

03:32 

1359 

GETwAMS 

2-OCT- 1985 

12:39 

1215 

DCLEDPLAN 

29-OCT-1985 

09:21 

781 

NAMES ECT 

29-OCT- 1985 

09:43 

1003 

GETSECT 

2-OCT- 193 5 

12:37 

937 

S ELS ECT 

2-OCT- 1983 

10:  59 

1019 

E-l 


* 

.  ■  »  » 

Form  name 

Creation  date/time 

Workspace 

,■•>  •> 

STUD5EL 

29-OCT-19S5 

09:34 

1103 

i 

« 

PRINTOPT 

1 8-OCT- 1985 

14:29 

585 

%%  % 

TAPESEL 

29-OCT- 198  5 

09:33 

1029 

SELALL 

1 9-NOV-198 5 

08:34 

773 

H  ‘‘'j 

WORK ON 

22-OCT-1985 

08  :  32 

855 

<  ■  «, 

Sv* 

DELNAME 

24-OCT-1985 

11:56 

631 

*■  U‘* 

STDTMENU 

24-OCT-198  5 

10:  57 

615 

» 

DELMENU 

2  4-OCT- 198  5 

11:07 

659 

DELSECT 

24-OCT-198  5 

11:  59 

531 

>> 

Kyr 

WORK DEL 

24-OCT-1985 

12:01 

409 

l*V\ 

I.v"v 

ALLORSOME 

29-OCT- 19  8  5 

09:20 

675 

1  „  **" 

WORKONSECT 

2  5-OCT- 19  8  5 

11:12 

403 

1  •  *•  V 

^  s 
■  -  ^  V 

5EQHELP 

19-NOV-1935 

08  :  37 

1021 

'®H 

SEQABW02 

19-NOV-198  5 

08  :  41 

3705 

■ 

NAMESECT2 

29-OCT-198  5 

09:47 

1043 

LISTSECT 

2 9-OCT- 19  8  5 

13:25 

711 

5EQPAGE 

30-OCT- 1985 

08:  53 

2139 

«"*V 

LOADING 

6 -NOV- 1985 

0  9:43 

645 

*  '*.  * 

GRAPHMENU 

8 -NOV- 19  8  5 

09:  47 

693 

>y> 

Aln 

NOSCREEN 

8-NOV-1935 

10:25 

159 

• 

GRAPHSEL 

7 -NOV- 198  5 

13:33 

989 

.\V 

2DPLANHELP 

1 9-NOV- 19  3  5 

08:53 

379 

■r.  * . 
v 

2DPLANHELP2 

19-NOV-1985 

08:55 

1153 
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Form:  EDPLAN1 
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Form:  HELPEOPL 
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1 234567890 1234567S90 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 


LISTED  BELOW  ARE  BRIEF  DESCRIPTIONS  OF  ALL  OF  THE  SELECTIONS 

1.  THIS  MODULE  ADDS  A  NEW  STUDENT  TO  THE  DATABASE  SYSTEM  AND 
THE  STUDENTS  EDUCATION  PLAN.  THE  STUDENT  SHOULD  KNOW 
HIS/HER  SOCIAL  SECURITV  NUMBER.  SECTION.  AND  FACULTY  ADVISOR. 

2.  THIS  MODULE  WILL  ALLOW  THE  USER  TO  CHANGE  ALL  OF  THE  INFORMATION 
ENTERED  IN  THE  ADD  ROUTINE  EXCEPT  THE  SOCIAL  SECURITY  NUMBER. 

3.  TO  DELETE  AN  EDUCATION  PLAN  FOR  A  STUDENT,  USE  THIS  SELECTION. 
NOTE:  THIS  WILL  NOT  DELETE  THE  STUDENT  FROM  THE  DATABASE. 

4.  THIS  IS  THE  SAME  AS  THE  UPDATE  ONLY  NO  CHANGES  WILL  BE  PERMITTED. 

5.  THIS  MODULE  WILL  LIST  THE  STUDENTS  IN  THE  DATABASE  BY  SECTION 
NAME. 

6.  THIS  MODULE  WILL  PRINT  AN  INDIVIDUALS  EDUCATION  PLAN. 

7.  THIS  MODULE  PRINTS  AN  ENTIRE  SECTIONS  EDUCATION  PLAN. 


I  234567890 1 234567890 1 234567890 1 234567890 1 2345678901234567890 1 234567890 1 234567B90 
'2  3  4  5  6  7  8 


m:  EDPLAN 
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AFITDB  DATABASE  V2 . 2 
STUDENT  EDUCA” I ON  PLANS 


1 . 

ADO  A  NEW  STUDENT  AND  EDUCATION  PLAN  | 

| 

2. 

UPDATE  A  STUDENT'S  EDUCATION  PLAN  i 

3. 

1 

DELETE  A  STUDENT'S  EDUCATION  PLAN 

4  . 

REVIEW  STUDENT'S  EDUCATION  PLAN 

5. 

LIST  STUDENTS  BY  SECTION 

6. 

PRINT  A  STUDENT'S  EDUCATION  PLAN 

7  . 

PRINT  A  SECTION'S  EDUCATION  PLAN 

8. 

CREATE  REGISTRAR  SUMMARY  FILE. 

9. 

EXIT  TO  PREVIOUS  MENU  I 

SELECT  OPTION  (1-9) 
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Form:  GETNAME 


Gl 


I 


i 


£1 


r3 


a 


T. 


I 


t 


P: 


O*. 


t  2  3  4  5  6^® 

12345678901234567890123456789012345678901234567890123456789012345678901234567890 


1  I 
2 ! 

3  I 

4  I 

5  I 
6 1 

7  I 

8  I 

9  I 
101 
111 
12l 
1  3  I 
1  4  | 
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21  I 

22  | 
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ENTER  THE  LAST  NAME  OF  THE  STUDENT 


ENTER  THE  LAST  NAME  OF  THE  STUDENT  WHOSE  RECORD  VOU  WISH  TO 
WORK  WITH.  IF  ONLY  ONE  STUDENT  IS  FOUND  WITH  THAT  LAST  NAME.  THEN 
HIS/HER  RECORD  WILL  8E  READ  AND  PRESENTED.  IF  MORE  THAN  ONE  STUDENT 
HAS  THAT  LAST  NAME.  ANOTHER  SCREEN  WILL  APPEAR  WITH  THOSE  STUDENTS 
THAT  MATCH  THE  ENTRY  ABOVE.  YOU  NEED  NOT  ENTER  THE  ENTIRE  LAST  NAME. 
ENTER  AS  MUCH  OF  THE  NAME  AS  POSSIBLE  TO  LIMIT  THE  POS I B1 LI T I ES .  TO 
EXIT  THIS  SCREEN,  HIT  RETURN  WITHOUT  ENTERING  ANY  CHARACTERS. 

DO  YOU  WISH  TO  PRINT  THE  LAST  PAGE  OF  THE  EDPLAN  REPORT (Y.N)  |  I 
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STUDENT  EDPLAN  DELETION 


STUDENT'S  LAST  NAME: 


ENTER  THE  WHOLE  OR  PARTIAL  LAST  NAME  OF  THE  STUDENT  WHOSE 
EDPLAN  YOU  WISH  TO  DELETE.  NOTE  THAT  THE  EDPLAN  AND  ONLY  THE 
EDPLAN  WILL  BE  DELETED.  THE  STUDENTS  RECORD  WILL  REMAIN.  TO 
EXIT  THIS  SCREEN  WITH  NO  CHANGE.  HIT  RETURN  WITHOUT  ENTERING  ANY 
CHARACTERS. 
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LIST  OF  STUDENT  BV  SECTION 
DISPLAY  ONLY 
SECTION: 


|  USE  ARROW  KEYS  TO  SCROLL  THE  SCREEN.  HIT  RETURN 
|  TO  EXIT  THE  SCREEN.  NOTE:  THIS  IS  A  DISPLAY  OF 
j  INFORMATION  ONLY.  USE  'E'  TO  EXIT  THE  SCREEN  OR 
|  HIT  THE  RETURN  KEY. 
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ENTER  THE  SECTION  CODE  OF  THE  CLASS  YOU  WISH  TO  WORK  WITH. 

IF 

1  10 

1  1  1 

THE  SECTION  YOU  ENTERED  IS  NOT  A  VALID  SECTION  THE  PROGRAM  WILL 

RETURN 
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TO  THE  PREVIOUS  MENU. 
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EDUCATION  PLAN  PRINT  OPTION 
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REGISTRAR  tape  builo  function 

( CREATES  STUDENT  SUMMARY . DAT  PILE  ) 


- - - - + 
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PLACE  AN  'X-  BESIDE  THE  SECTIONS  YOU  WISH 
TO  GENERATE  A  SUMMARY  FILE  FOR.  YOU  MAY 
UN-SELECT  A  SECTION  BY  PLACING  A  SPACE  IN  THE 
MARKER  to  the  LEFT.  TO  EXIT,  HIT  RETURN,  TO 
EXIT  ANO  CANCEL  ,  ENTER  AND  'E'. 
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SUMMARY  FILE  GENERATION  FUNCTION 


THIS  MODULE  ALLOWS  THE  USER  TO  GENERATE  THE  SUMMARY  FILE  NEEDED 
BY  THE  REGISTRARS  OFFICE  TO  SCHEDULE  CLASS.  SUMMARYS  CAN  BE 
GENERATED  FOR  ALL  OF  THE  SECTIONS  OR  JUST  SELECTED  SECTIONS. 


1  GENERATE  SUMMARY  FILE  FOR  ALL 
SECTIONS. 

2  SELECT  SPECIFIC  SECTIONS  TO  BE 
GENERATED. 

9  EXIT  TO  PREVIOUS  MENU. 

SELECT  OPTION  (1,2.9)==> 
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SUMMARY  FILE  GENERATION 
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AFITDB/ENG  STUDENT  DATABASE 


1.  ADD  A  STUDENT  TO  THE  DATABASE. 

2.  UPDATE  A  STUDENTS  PERSONNEL  RECORD. 

3.  DEL  A  STUDENT ( S )  FROM  THE  DATABASE  (ARCHIVE) 

4.  UPDATE  A  STUDENTS  PERSONNEL  RECORD. 

5.  RUN  THE  EDUCATION  PLAN  PROGRAM. 

9.  EXIT  TO  PREVIOUS  MENU. 

SELECT  OPTION  (1-5,9)«=» 
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DELETE  STUDENT  FUNCTION 


THIS  FUNCTION  REMOVES  THE  STUDENT  OR  STUDENTS  FROM  THE  DATABASE 
SYSTEM  AND  STORES  ALL  OF  THEIR  INFORMATION  IN  FILE  CALLED  ARCHIVE . DAT . 
YOU  CAN  EITHER  REMOVE  A  SINGLE  STUDENT  OR  ARCHIVE  AN  ENTIRE  SECTION. 

1  DELETE  A  STUDENT  BY  NAME. 


2  DELETE  AN  ENTIRE  SECTION. 

9  EXIT  TO  PREVIOUS  MENU. 

SELECT  OPTION (1 ,  2 , 9 ) =*> 
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DELETE  AND  ARCHIVE  AN  ENTIRE  SECTION 


ENTER  THE  SECTION  COOE  ==>  | 


ARE  YOU  SURE  YOU  WISH  TO  DO  THIS.  (Y.N)  |  | 
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CURRENTLY  ARCHIVING  AND  DELETING  : 


(PLEASE  STAND  BY:) 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
1  1 
12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 
23 


12345678901234567890123456789012345678901234567890123456789012345678901234567890 
1  2  3  4  5  6  7  8 


Form:  ALLORSOME 


12  3  4  5  6  7  8 

1 2345678901234567890123456789012345678901234567890123456789012345678901234567890 


1  I 
21 
31 

4  I 

5 
6| 

7  | 

8  | 
9  | 

1  0  j 
'  1  I 
1  2  | 
1  3  | 
1 4  j 
15| 
1 6 1 
1  7  j 
1  8  | 
191 
20| 

21  I 

22  | 
231 


SELECT  AN  ENTIRE  SECTION  TO  BE  PRINTED 
OR  SELECTED  STUDENT  WITHIN  A  SECTION 


PRINT  ALL  STUDENTS  EDPLANS  WITHIN  A  SECTION . 

PRINT  SELECTED  STUDENTS  EDPLAN  WITHIN  AN  SECTION. 
(  AN  ADDITIONAL  SCREEN  WILL  APPEAR  TO  ALLOW  ) 

(  YOU  TO  PICK  THE  STUDENTS  TO  BE  PRINTED.  ) 

EXIT  TO  PREVIOUS  FUNCTION. 


SELECT  OPTION  (1,2,9)==> 
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ENTER  TO  the  LEFT  OF  THE  COURSE.  THE  TYPE  OF  SEQUENCE  THE  COURSE 
BELONGS  to.  FOR  INSTANCE.  EENG799  WILL  ALMOST  ALWAVS  BE  THE 
THESIS  COURSE  ANO  SHOULD  CONTAIN  AN  ENTRY  'THES*.  OTHER  VALID 
SEQUENCE  COOES  UNDG , SEQA . SEQB . MATH , WA I V .  AS  A  SHORT  CUT.  THE  FOLLOWING 
ONE  LETTER  COOES  CAN  BE  ENTERED  IN  PLACE  OF  TYPING  THE  ENTIRE  FOUR 


LETTER  CODE: 


A 

8 

M 


SEQA 

SEQB 

MATH 


W  =  WA I V 
U  =  UNDG 

OR  A  SPACE  WILL  DELETE  THE  FIELD 

ENTER  THE  CODE  AND  HIT  TAB  OR  RETURN  AND  THE  ACTUAL  COOE  WILL  APPEAR. 
TAB,  BACKSPACE,  ANO  RETURN  KEYS  ALLOW  YOU  TO  TRAVERSE  THE  LIST  THE 
FUNCTION  WILL  NOT  TERMINATE  UNTIL  THE  CURSOR  PASSES  THE  LAST  FIELD  ANO 
THE  RETURN  KEY  IS  HIT. 
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SEQUENCE  DECLARATION 

THE  FOLLOWING  COURSES  REPRESENT  THE  SEQUENCES  AS 
THEY  CURRENTLY  EXIST  IN  THE  COURSE  FILES.  SEQA  REPRESENTS  THE 
DEGREE  REQUIRED  COURSES.  SEQB  REPRESENTS  THE  SEQUENCE  COURSES, 
MATH,  THES,  AND  WAIV  REPRESENT  MATH,  THESIS  AND  WAIVED  COURSE. 
UNDO  REPRESENT  THE  UNDERGRADUATE  COURSES. 
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i  USE  ARROW  KEYS  TO  SCROLL  THE  SCREEN.  HIT  RETURN  | 

I  TO  EXIT  THE  SCREEN.  PUT  AN  'X'  BESIDE  THE  NAMES  | 

I  OF  THOSE  STUDENTS  WHOSE  EDPLAN  YOU  WISH  TO  PRINT,  j 
I  ENTER  AN  'E'  TO  CANCEL  THIS  FUNCTION.  j 
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LIST  OF  STUOENTS  BY  SECTION 


ENTER  SECTION  =  1 


ENTER  THE  SECTION  COOE  OF  THE  CLASS  YOU  WISH  TO  WORK  WITH.  IF 
THE  SECTION  YOU  ENTERED  IS  NOT  A  VALID  SECTION  THE  PROGRAM  WILL  RETURN 
TO  THE  PREVIOUS  MENU.  THE  LIST  OF  STUDENTS  ASSOCIATED  WITH  THE  SECTION 
WILL  APPEAR  ON  THE  NEXT  SCREEN  IN  A  SCROLLED  AREA. 
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1|  SEQUENCE  DECLARATION  DISPLAY 

2 |  SEQUENCE  A:  DEGREE  REQUIRED  COURSES: 


5 1  SEQUENCE  B:  REQUIREO  SEQUENCE  COURSES 


MATH  COURSES 


1  1  I  THESIS  COURSE 


1 4 1  OTHER  GRAC'TE  COURSES 


18 1  UNOERGRADUATE  COURSES 
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GRAPHIC  DEMONSTRATION  PROGRAM 


1.  GRAPH  NUMBER  OF  STUDENTS  IN  A  SECTION 

2.  GRAPH  NUMBER  OF  STUDENTS  IN  A  COURSE 

3.  SET  MODE  TO  PLOTTER 

4.  SET  MODE  TO  SCREEN  (DEFAULT) 

5.  AFIT/ENG  FACULTY  WORKLOAD  (USING  FMS ) 

6.  AFIT/ENG  DEPARMENT  WORKLOAD  (USING  FMS) 
9.  EXIT  PROGRAM 

SELECT  OPTION  (l-4,9)==> 
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SELECT  SECTIONS  TO  BE  GRAPHED 
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PLACE  AN  *  A'  BESIDE  THE  SECTIONS  YOU  WISH 
TO  GENERATE  A  SUMMARY  FILE  FOR.  YOU  MAY 
UN-SELECT  A  SECTION  BY  PLACING  A  SPACE  IN  THE 
MARKER  TO  THE  LEFT.  TO  EXIT,  HIT  RETURN.  TO 
EXIT  ANO  CANCEL  .  ENTER  AND  'E'. 
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APPENDIX  F 

Data-set  Requirement  Tabulations 
This  part  of  the  appendix  was  obtained  from  Maj  Pangmans 
Thesis  on  the  AFIT/EN  Database  System  (2).  The  left  side  of  this 
appendix  lists  the  specific  requirements  requested  that  the 
expanded  AFIT  Database  accommodate,  while  the  right  side  show  the 
subsequent  location  where  ethe  requirement  has  been  included 
within  it.  The  data  requirements  obtained  by  'interviews'  also 
consisted  of  the  repeat  conversation  with  administrative 
personnel  as  will  as  those  originally  interviewed.  This  document 
was  used  to  check  the  requirements  requested  against  the  atomic 
values  needed  to  support  those  re-quirements .  Those  requirements 
items  which  have  more  than  one  data-set  listed  as  the  location 
where  the  requirement  is  found  indicate  that  either  area  could 
contain  such  data  depending  on  the  application  progoram  or  that 
the  application  program  requ'ired  to  obtain  such  data  can  do  so 
utilising  the  listing  data-set  links. 


REQUIREMENT  DATA 


TABLE  DATA  -  WHERE  THE 
REQUIREMENT  DATA  ARE  LISTED 
IN  THE  DATA-SET 


Change  the 

thes  i 

s  course  cr ed i 

MCRS 

-  Course  control 

from  A  to  any  number  of  hours. 

number  has 

s  i  x 

digits 

(ex  . 

ec79A  -  1  cr 

edit 

hour  ) 

Fac  Advisor 

--  > 

Students 

FADV 

-  Linked  to 

FACT 

, STDT , 

Fac  Advisor 

--> 

Thes  Students 

SECT 

Student 

--> 

Fac  Advisor 

TADV 

-  Linked  to 

FACT 

f  j  i  j  i  t 

Student 

--> 

Thes  Advisor 

THES 

Thesis  Data 

-->  Student 

STDT 

Adv i sor 

TADV 

Box  Number 


STDT 


5.  Course  Listing  --> 


6.  Projected  enrollment 


7.  Ed  Plan 


—  > 


'caching  Loads 


Class 

SECT 

Thesis  Topic  (Title?) 

TIITL 

Committee  Members 

TCMF 

Thesis  Title 

THTL 

irse  Listing  --> 

Instructors 

FACT 

Course  Linsting 

MCRS 

Title 

MCRS 

Course  Number 

MCRS 

Number  Credit  Hour 

MCRS 

Quar  te  r 

MQTR 

Course  Text 

MBKT 

Instructor 

VI  NS 

;s  -->  Course 

MCRS 

Number  of 

MCRS 

Hours 

Quarter 

MQTR 

Number  of 

VNMC 

Books  to  order 

Student  Name 

STDT 

SSAN 

STDT 

Course (Mum.  &  Title) 

MCRS 

Section  (Size  Limit) 

MCRS 

Credit  Hours 

MCRS 

Class 

SECT 

Quar  ter 

MQRT 

Grades 

CRSE 

Prerequisi tes 

MREQ 

Waiver 

CRSE 

Course  Sequence 

MSST 

a.  Instructors  Name 

FACT 

b.  Course (s)  Taught 

MCRS, 

c.  Quarter 

MQTR 

d.  Type  of  Course 

MCRS 

a.  Number  of  Section 

MCRS 

f.  Number  of  Thesis/ 

Instructors 

FACT, 

g.  Short  Terra  Hours 

MCRS, 

Taught 

h.  Profssional 

Developement 

Quarter  Listing 

VP  DQ 

i.  Faculty  Advisor 

Listing 

FADV 

j.  Thesis  Committee 

Listing 

TCMF 

:qr 


/TADV/THES 


0. 


Course  Data 


-->  Student  Name 
SSAN 


STDT 

STDT 


Service 

Rank 

Class 

Home  Telephone 
Box  Humber 


STDT 

STDT 

STDT/SECL/ SECr 

STDT 

STDT 


13.  Instructor 
Stati sties 


■>  Instructor  Name  FACT 

SSAN  FACT 

Courses  Taught  MCRS 

Students  In  Course  by: 

Name  STDT 

SSAN  STDT 

Class  SECL 

Grades  CRSE 


11.  Catalo  Faculty 
Publications- 


12.  Room  Usage 


•>  Name 
SSAN 
Title 
Date 
Topic 


(TITLE) 


Room  Location 
Room  Capacity 
Time  Schedule 


FACT 

FACT 

FCOM 

FCOM 

FCOM 

BLRM 

CPTY 

TIME/ DAYS/ SCHD 


13.  Projected 

Enrollments 


Course 
Quarter 
Student  SSAN 
Student  Name 
Student  Clas: 


MCRS 

MQTR 

nmnn 
J  .  U  i 

STDT 
S  EC L 


14.  Prof f essional 
Duties 


■>  Awards  FHAIJ 

Committee  Membership  FCMT 
Committee  Duties  FCMT 

Professional  Soc .  FSOC 

Interest  Area  FIN 2 


Student  Data 


•>  Name  STD? 

SSAN  STDT 

Box  Number  STDT 

Home  Phone  Number  STDT 

Advisor  TADV 

Class  SECT 

Service  STDT 

Graduated  AFIT?  STDT 


16.  Graduate  Record- 
Data 


■>  Verify  Degree 
Re quire me nts 
Course  Sequences 
Course 

Math  Credits 


MDEG 

MSSF 

MCRS 

MCRS 


V>i>5y‘ 


APPLICATIONS  SOFTWARE  REQUIREMENTS  LIST 


This  portion  of  the  requirements  list  specifies  the 
requirements  for  the  application  software  and  computer  interface 
requirements.  The  requirements  are  numbered  for  easier  reference 
in  the  thesis. 

1.  Database  Schema  Enhancements  and  Mod i f i ca t ions 

1.1  Graduate  Credit  Record  Modification. 

1.1.1  Remove  the  student  social  security  number  link 
from  the  Variable  Sequence  File  and  from  the  Master  Student  File. 

1.1.2  Remove  references  to  the  student  social  security 
number  link  from  all  other  files. 

1.2  Text  Book  file  modification. 

1.2.1  Text  book  file  and  book  file  contain  duplicate 
information.  Delete  the  text  book  file  from  the  database. 

1.2.2  Remove  all  references  to  the  text  book  file  from 
other  files. 

1.3  Course  Field  Modification. 

1.3.1  Increase  the  field  size  from  6  characters  to  8 
characters  to  make  the  field  compatible  to  other  database 
systems . 

1.4  Thesis  Catalog  File  (NTIC). 

1.4.1  Information  contained  in  the  variable  files 
belongs  in  the  Master  Thesis  File  (TFIE3).  The  variable  files  must 
contain  links  only  to  allow  for  deletion  of  stjdents  and  faculty. 

1.4.2  Thesis  Catalog  file  and  Thesis  file  contain 
duplicate  information.  The  Thesis  Catalog  file  should  be 
removed  from  the  schema  and  all  links  removed  from  the  system. 

1.4.3  Re-generate  the  database  using  the  new  file 

system. 


2.  Functional  Requirements. 

2.1  Functional  file  grouping.  There  are  five  distinct  file 


groups.  Each  one  is  to  be  maintained  by  a  seperately  compiled 
program  to  aid  in  modularity  and  design. 


2.1. 


Faculty:  Maintains  faculty  master  file, 


F-4 


department  master  file  and  related  variable  files. 

2.1.2  Student:  Maintains  the  student  master  file, 
education  plans  and  related  variable  files. 

2.1.3  Courses:  Maintains  the  master  course  file, 
master  textbook  file,  day  file,  time  file,  room  capacity  file, 
and  quarter  file  as  well  as  the  related  variable  files. 

2.1.4  Thesis:  Maintains  the  thesis  master  file  and 
controls  the  links  to  students,  faculty, and  departments. 

2.1.5  Sequence  and  Degree  Modules:  Maintains  the 
master  sequence  file,  master  degree  requirement  file  and 
associated  variable  files. 

2.2  Standard  Database  Functions. 

2.2.1  Add:  Adds  a  record  to  the  database.  This 
involves  adding  a  master  record  and  associated  variable  records 
if  necessary. 

2.2.2  Update:  Updates  a  master  record  and  in  the 
database.  Must  be  able  to  detect  if  the  record  exists  and  update 
associated  variable  records. 

2.2.3  Delete:  Delete  a  master  record.  In  some  cases 
such  as  for  the  faculty  and  students  records,  the  data  should  be 
archived  for  historical  data  and  records.  Thesis  information 
should  be  kept  for  student  database  searches. 

2.2.1  Review:  Scan  the  information  in  a  master  record 
and  link  variable  records  in  read  mode  only.  Maintain  the 
ability  to  print  the  information. 

2.2.5  WRMXXXX :  '..’rite  an  updated  master  file  record  to 
the  AFIT  Database  where  "XXXX"  is  the  four  character  file  code. 

2.2.6  RDMXXXX:  Read  a  record  from  the  master  file  of 
the  AFIT  Database  where  "XXXX"  is  the  four  character  file  code. 

2.2.7  DLMXXXX:  Delete  a  master  record  from  the  AFIT 
Database  and  all  of  the  associated  variable  records.  "XXXX" 
designates  the  four  character  file  code. 

2.2.3  ADMXXXX:  Add  a  new  record  to  the  AFIT  Database 
system  where  "XXXX"  is  the  four  character  file  code. 

2.2.9  ADCXXX:  add  a  variable  record  continue,  adds  a 
record  after  the  current  record  pointed  to. 

2.2.10  ADA XX XX :  Add  a  variable  record  after  the  second 
record  pointed  to. 

2.2.11  AD3XXXX:  Add  a  record  before  the  one  pointed  to 


in  the  record  string. 

2.2.12  RDVXXXX:  Read  the  next  variable  record  in  the 
string  or  records. 

2.2.13  RDRXXXX :  Read  the  previous  variable  record  in 
the  string. 

2.2.14  RDDXXXX:  Read  direct.  Reads  the  record  directly 
pointed  to  by  the  reference  pointer. 

2.2.15  WRVXXXX:  Writes  a  variable  record  back  to  the 
database  system  that  previously  existed. 

2.2.16  DLDXXXX:  Deletes  a  record  pointed  to  by  the 
reference  pointer. 

2.3  Database  Limitations.  These  limitations  apply  to  the 
database  generation  because  TOTAL  allocates  the  disk  space  for 
the  entire  file  system  at  once.  Disk  space  must  be  contiguous. 

2.3.1  Faculty  file  limitations 

Room  should  be  allocated  for  200  people  in 
the  database  with  460  bytes  for  each  individual.  Blocksize  of 
the  record  should  be  5  records  or  2560  bytes. 

2.3.2  Student  file  limitations: 

Space  should  be  allocated  for  585  students  in 
the  database  with  463  bytes  per  student.  The  blocksize  of  the 
file  should  be  the  same  as  the  faculty  (2560  nyte  blocks). 

2.3.3  Department  file  limitations: 

There  are  currently  five  departments, 
however,  space  should  be  allocated  for  seven  in  case  of  growth. 
Each  records  should  contain  40  bytes  and  the  blocksize  should  be 
set  to  512  bytes. 


2.3.4  Thesis  file  limititutions: 

At  this  time,  space  should  be  allocated  for 
585  thesis  which  is  identical  to  the  number  of  students  enrolled. 
Each  record  contains  232  bytes,  blocksiz?  should  be  set  at  922 
bytes . 


2.3.5  Class  section  limitations: 

With  the  ability  to  overlap  the  number  of 
section  a  degree  is  offered  to,  space  for  33  sections  should  be 
allowed.  Each  section  requires  56  bytes  and  a  blocksize  of  144 
bytes  . 


2.3.6  Course  file  limitations: 

The  number  of  course  required  to  be  store  is 
542.  This  allows  for  a  ten  percent  growth  in  the  next  year.  Each 
record  requires  128  bytes  with  a  block  size  of  1024. 


2.3.7  Class  quarter  limitations: 


The  number  of  quarters  is  expected  to  remain 
the  same.  Space  should  be  allocated  for  3  years  of  classes,  or  12 
quarters.  Each  record  requires  40  bytes  with  a  block  size  of  480 
bytes  per  block. 

2.3.3  Course  Book  limitations:  Each  course  will 
require  on  the  average  of  2  books.  With  a  set  number  of  classes 
at  542,  storage  must  be  made  available  for  1084  books.  Each 
record  requires  133  with  a  blocksize  of  393  bytes. 

2.3.9  Class  time  limitations: 

With  each  class  time  starting  on  the  hour 
between  the  hours  of  0830  and  1700,  there  are  10  class  times.  To 
accomodate  special  requests,  an  additional  5  classes  will  be 
added.  Room  should  be  made  available  for  15  classes,  each  record 
requies  20  bytes  with  a  blocksize  of  500. 

2.3.10  Building  and  Room  limitations: 

The  only  capacity  for  the  rooms  ever  put  on 
che  current  database  is  30,  which  is  the  enrollement  limitation. 
However,  room  should  be  allowed  for  10  records  for  the  room 
capacity  and  130  rooms  total  for  the  Master  Building  and  Room 
file.  The  Master  Room  capacity  file  requires  20  bytes  per 
record  and  400  byte  blocksize  and  the  Master  Building  and  Room 
file  needs  32  bytes  per  record  and  a  512  bytes  per  block. 

2.3.11  Degree  and  Sequence  limitations: 

Because  of  the  changing  requirements,  these 
two  files  should  be  allowed  their  total  capacity  of  100  and  1839 
records  respectfully.  The  Master  Sequence  File  should  allow  for 
1300  records  with  each  record  requiring  GO  bytes  and  512  byte 
blocksize.  The  Master  Degree  Requirement  file  needs  56  bytes  per 
record  and  512  byte  blocksize. 

2.*  Response  Time  Requirments.  The  objective  is  to  keep 
response  time  to  a  minimum.  Because  of  the  relative  low  number  of 
records  that  are  in  each  file,  (less  then  403  on  the  average) 
this  can  be  done  by  keeping  an  internal  list  of  files  in  a  simple 
links  list  structure.  There  are  currently  a  need  for  the 
following  linked  list  structures. 

2.4.1  Student  file:  Keep  track  of  the  students  name, 
social  security  number,  class  section,  and  box  number.  Define 
add,  update,  delete  and  find  operations  on  this  list. 

2.4.2  Faculty  file:  Keep  track  of  the  faculty  names, 
social  security  number,  and  advisor  section.  Define  the  add, 
update,  delete,  and  find  operations  on  this  list. 

2.4.3  Class  Section:  Keep  3  sorted  list  of  class 
sections,  advisors,  and  section  leaders  in  a  linked  list.  Define 
the  Add  and  find  operations  on  the  structure. 


2.5  Required  Reports. 

2.5.1  Division  Faculty  Schedule  and  Manpower 
Requirements  Expenditure  Document:  See  this  Appendix  Ear 
examples  of  these  documents. 

2.5.2  Education  Plans:  Contains  the  students 
information,  class  schedule  by  quarter,  sequence  A  and  B. 

2.5.3  Listing  of  Enrolled  Students:  Give  the  students 
enrolled  in  courses  at  AFIT  by  department  and  section  numbers. 

2.5.4  List  Courses  and  information  on  when  they  are 
offered,  credit  hours,  and  instructors. 

2.5.5  Student  Locator  listing:  Contains  the  information 
currently  contained  on  the  student  locator  cards  in  the  ENA 
office. 

2.6  Data  Syntax:  See  Appendix  C  for  a  complete  list  of  data 
syntax  and  compatibility  tests  to  be  performed  on  the  data  items 
to  protect  the  data  integrety. 

3.  Computer  Interface  Requirements. 

3.1  Identify  targeted  user  group  and  develop  system  on  the 
critera  of  the  average  user  as  defined  by  this  thesis. 

3.2  Develop  a  prototype  of  the  Education  Plan  program  to 
demonstrate  to  possible  users  for  feedback  on  "user-friendliness" 
of  the  system. 

3.3  Develop  menus  for  the  system  that  are  standard  in 
structure  and  self  documenting.  No  more  than  seven  selections 
should  oo  on  any  one  menu. 

3.  ’•  Item  Selection:  Whenever  possible,  let  the  user  select 
from  a  group  of  items  such  as  course  to  eliminate  the  need  to 
type  in  data.  This  should  enhance  data  integrety  and  make  the 
system  simpler  to  use.  ‘lake  the  selection  as  narrow  as 
possible.  For  instance,  if  selecting  from  a  group  of  classes, 
allow  the  user  to  ask  for  only  EENG  classes  or  CAT'!  classes. 
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SCHOOL  OF  ENGINEERING  STUDENT  RECORD 
CPT  4924  GE-B5D 

PLAN  INITIAL  _  REVISED  _  FINAL  _ 

PROGRAM  APPROVAL:  MS. 

ADVISOR _ _  ACADEMIC _  THESIS _ 

*QTR-YR*  NUMBER  COURSE  TITLE  HRS  GRADE  PTS 

SUMMER  1984 _ 


MATH531 

MATH  METHODS  OF  COMPUTE 

4 

MATH592 

MANAGERIAL  STATISTICS  I 

3 

C0MM600 

TECHNICAL  WRITING 

2 

MATH445 

INTRO  TO  ALGORITHM  DESI 

4 

CUM  HRS:  13  CUM  GPR  GTR 

HRS 

13 

QTR 

GPR: 

fall 

1984 

EENG450 

INTRO  TO  LOGIC  DESIGN 

5 

MATH692 

MANAGERIAL  STATISTICS  I 

3 

EENG586 

INFO  STRUCTURES 

4 

EENG589M 
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ABSTRACT  DATA  TYPE  DEFINITIONS 
STUDENT  AND  FACULTY  LINKED  LIST  ABSTRACT  DATA  TYPE. 

The  AFIT/ENG  Database  system  requires  that  sorting  and 
searching  must  be  accomplished  on  the  faculty  and  student  data 
names  in  a  highly  volotile  environment.  To  facilitate  this 
highly  dynamic  arena,  an  internal  list  of  the  data  must  be  kept 
and  maintained.  The  data  type  is  implemented  with  a  singly 
linked  list  using  pointers  and  a  dynamic  memory  allocation 
scheme.  Modules  should  be  independent  of  global  variables  to 
make  transporting  and  maintenance  easier.  The  following  data 
type  and  modules  should  be  defined  for  all  applications  of  the 
master  student  and  faculty  files: 


type 

LINK_PTR  =  “LINK_RECORD; 
LINK  RECORD  =  RECORD; 


NAME 

3UFF28 ; 

CTRL 

BUFF 9 ; 

RANK 

BUFF  3  ; 

DEPT 

BUFF A ; 

SECT 

BUFFS  ; 

NEXT 

LINK  PTR; 

PREV 

LINK  PTR; 

END;  {*  LINK  RECORD  *} 


MODULE  NAME 

PARAMETERS 

FUNCTION 

BUILDLINKLI5T 

LINK  PTR, FILE 
HEADER) 

Reads  the  database  master  student 
or  faculty  file  sequentially  and 
inserts  the  name  and  data  into  the 
list. 

ADDNAME 

LINK  PTR, FILE 
HEADER 

Adds  a  record  to  the  link  list  in 
alphabetical  order.  The  HEADER 
parameter  will  point  to  the  faculty 
or  student  list. 

DELNAME 

SSAN, HEADER 

Deletes  a  record  from  the  list  for 

FINDNAME 


NAME, S SAN 
LINK  PTR 


vV 


•V! 


IS EMPTY 
CREATE 


HEADER 

HEADER 


Finds  a  record  using  the  last  name 
as  a  key  or  a  portion  of  the  last 
name.  For  instance,  this  routine 
would  find  the  first  occurance  of 
the  name  that  began  with  the  letter 
"G".  The  search  starts  at  the  next 
position  from  LINK_PTR  but  not  in¬ 
clusive  . 

Detemines  if  the  list  is  empty. 
Creates  a  header  record  for  a  list. 


Student  and  Faculty  List  Axiom  definition 

Structure  LINKLIST (LINK_PTR, HEADER, FILE) 

DECLARE  CREATE (HEADER)  ==>  HEADER; 

3UILDLINKLIST ( HEADER , FILE)  ==>  HEADER 
ADDNAME (LIMK_PTR, HEADER)  ==>  HEADER 
DELNAME (LIMK_PTR, HEADER)  ==>  HEADER 
ISEMPTY (HEADER)  ==>  BOOLEAN 
FOR  ALL  A  in  LINKLIST,  ptr  as  L I NK_PTR ,  file  as  FILE, 
head  as  HEADER,  LET 
ISEMPTY (CREATE (head) )  ::=  true; 

ISEMPTY (ADDNAME (ptr, CREATE (head) ) )  ::=  false 

DELNAME (ptr , ADDNAME (ptr , head) )  ;;=  head 

DELNAME (ptr , CREATE (head ) )  error 

end 

end  LINKLIST 
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Appendix  H 

STANDARD  DATABASE  ROUTINES 

These  routines  are  required  to  enable  the  application 
programmers  to  interface  with  the  Total  Database  Management 
System  in  an  easier  fashion.  By  doing  this,  we  hope  to  decrease 
the  amount  of  time  involved  in  developing  the  required  software 
and  in  training  personnel  to  maintaining  the  programs. 


MODULE  NAME  PARAMETERS  FUNCTION 


SIGN  "SINON,SINOF"  Log  onto  the  database  system. 


SCHEMALOAD 

CHECKSTATUS 

ERRORCODES 

WAIT 

OUTPUTERROR 

WRMXXXX 

RDMXXXX 


SCHEMA  Defines  the  parameters,  files,  and 

file  disposition  of  the  database  at 
the  time  of  "SINON” 

STATUS, OK  Checks  the  return  status  of  a  call 
to  the  database  system.  Calls  an 
error  routine  in  case  the  status  is 
not  "****". 


STATUS 

TIME 

STATUS 

XXXX_REC 

XXXX  REC 


Displays  the  message  associated 
with  the  error  code  to  the  user 
and  waits  for  8  seconds  before 
clearing  the  sc'reen. 

Performs  a  wait  function  which  may 
allow  the  user  to  view  a  message 
before  the  next  function  is 
displayed . 

Maintains  the  error  messages  for 
the  TOTAL  DBMS  system. 

The  generic  write  master  file 
routine  used  to  generate  a  write 
master  routine  for  a  specific 
master  file. 

The  generic  read  master  file 
routine . 

The  generic  add  master  record 
routine.  The  control  key  must  be 
asssigned  to  XXXX.CTRL  before  the 
call . 


ADMXXXX 


XXXX  REC 


The  following  Pascal  program  procedures  are  the  complete  set 


of  standard  routines  developed  and  used  thoughout  this  effort. 
The  programs  reside  in  a  single  file  and  are  read  into  another 
file  when  creating  an  application  software  package  for  the 
AFIT/ENG  Database  System.  The  standard  data  types  must  also  be 
included  in  the  file  if  these  routines  are  to  be  used. 
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DATE:  30/05/85  *} 

NAME:  WAIT  *} 

DESCRIPTION:  THIS  MODULE  ALLOWS  THE  PROGRAMMER  TO  SPECIFY  AN  *} 

A  WAITING  PERIOD  BEFORE  GOING  TO  THE  NEXT  INSTRUCTION.  *} 
THIS  IS  USEFUL  THAT  WHEN  DISPLAYING  ERROR  MESSAGES  TO  *} 
THE  USER  AND  ALLOWING  THE  USER  TO  SEE  THE  MESSAGE  WITH-  *} 
OUT  HITTING  RETURN  TO  CONTINUE.  *} 

GLOBAL  VARIABLES  USED:  NONE  *} 

GLOBAL  VARIABLES  CHANGED:  NONE  *} 

MODULES  CALLED:  NONE  *) 

CALLING  MODULES:  OUTPUTERROR  *) 

AUTHOR:  CAPT  DAVID  A.  GAITROS  *) 


PROCEDURE  WAIT  (  WAITVAR:  INTEGER); 

VAR  INDEX, I  :  INTEGER; 

BEGIN 

I  :-  1; 

FOR  INDEX  :a  1  TO  WAITVAR*  100  DO 
I  :=»  INDEX 
END;  {*  WAIT  *} 


{*  DATE:  30/05/1985 

{*  NAME:  OUTPUTERROR 

{*  DESCRIPTION:  THIS  MODULE  ACCEPTS  THE  ERROR  CODE  FROM  THE 

{*  DATABASE  AND  TRANSLATES  THAT  INTO  AN  ERROR  MESSAGE. 

{* 

{*  GLOBAL  VARIABLES  USED:  NONE 

{*  GLOBAL  VARIABLES  CHANGED:  NONE 

{*  MODULES  CALLED:  NONE 

{*  CALLING  MODULES:  CHECKSTATUS 

{*  AUTHOR:  CAPT  DAVID  A.  GAITROS 

{i* 

PROCEDURE  OUTPUTERROR( STATUS  :  BUFF4) ; 

BEGIN 

WRITE  ('  ***  ERROR  STATUS  CODE  ***»'); 

WRITE  (  STATUS); 

WRITELN; 

IF  STATUS  =  "BCCR"  THEN 

WRITELN ( OUTPUT , '  BAD  CYLINDER  CONTROL  RECORD  ') 

ELSE  IF  STATUS  =»  "BCTL"  THEN 

WRITELN (OUTPUT,"  BLANK  CONTROL  FIELD  ') 

ELSE  IF  STATUS  »  "DBNF"  THEN 

WRITELN( OUTPUT,"  DATA  BASE  NOT  FOUND  ") 

ELSE  IF  STATUS  -  "DBPR"  THEN 

WRITELN( OUTPUT,"  DATA  BASE  ACCESSED  IN  PRIVATE  MODE  ") 
ELSE  IF  STATUS  -  "DUPM"  THEN 

WRITELN (OUTPUT,"  DUPLICATE  MASTER  RECORD  ') 

ELSE  IF  STATUS  -  "DUPO"  THEN 

WRITELN( OUTPUT,"  DUPLICATE  OPEN  OF  A  DATA  SET  ') 

ELSE  IF  STATUS  -  "ENTF"  THEN 

WRITELN( OUTPUT,"  ELEMENT  NOT  FOUND  ") 

ELSE  IF  STATUS  =*  "EXSO"  THEN 

WRITELN( OUTPUT,"  EXTRA  SINON  COMMAND  ') 

ELSE  IF  STATUS  *  "FAIL"  THEN 

WRITELN (OUTPUT,"  COMMUNICATION  FAILURE  (F)  ') 

ELSE  IF  STATUS  =  "FATL"  THEN 

WRITELN( OUTPUT,"  FATAL  ERROR  ') 

ELSE  IF  STATUS  =  "FNOP"  THEN 

WRITELN( OUTPUT,"  FILE  NOT  OPEN  ') 

ELSE  IF  STATUS  =•  'FNTF'  THEN 

WRITELN( OUTPUT,"  FILE  NOT  FOUND  ') 

ELSE  IF  STATUS  *  'FTYP'  THEN 

WRITELN( OUTPUT,"  INVALID  FILE  TYPE  ") 

ELSE  IF  STATUS  =  'FULL'  THEN 

WRITELN (OUTPUT,"  FILE  LOADED  TO  CAPACITY  ') 

ELSE  IF  STATUS  *  "FUNC"  THEN 

WRITELN( OUTPUT,"  INVALID  FUNCTION  CODE  ') 

ELSE  IF  STATUS  -  'HELD'  THEN 

WRITELN( OUTPUT,"  RECORD  HELD  ') 

ELSE  IF  STATUS  -  'ICHN'  THEN 

WRITELN (OUTPUT,"  INVALID  LINKAGE  PATH  CHAIN  ') 

ELSE  IF  STATUS  -  'IMDL'  THEN 

WRITELN( OUTPUT,"  INVALID  MASTER  DELETE  ') 


ELSE  IF  STATUS  «  'IOER'  THEN 

WRITELN( OUTPUT,'  I/O  ERROR  (F)  ') 

ELSE  IF  STATUS  =  'IPAR'  THEN 

WRITELN( OUTPUT,'  INVALID  NUMBER  OF  PARAMETERS  ') 

ELSE  IF  STATUS  «  'IRLC'  THEN 

WRITELN( OUTPUT,'  INVALID  RECORD  LOCATION  (F)  ') 

ELSE  IF  STATUS  -  'IVBF'  THEN 

WRITELN( OUTPUT,'  INVALID  BUFFER  SIZE  ') 

ELSE  IF  STATUS  -  'IVRC'  THEN 

WRITELN( OUTPUT,'  INVALID  RECORD  CODE  ') 

ELSE  IF  STATUS  -  'IVRD'  THEN 

WRITELN( OUTPUT,'  INVALID  VARIABLE  ENTRY  DATA  SET  READ  ') 

ELSE  IF  STATUS  -  'IVRP'  THEN 

WRITELN( OUTPUT,'  INVALID  REFERENCE  PARAMETER  ') 

ELSE  IF  STATUS  -  'IVTF'  THEN 

WRITELN( OUTPUT,'  INVALID  TOTAL  FILE  ') 

ELSE  IF  STATUS  -  'IVWD'  THEN 

WRITELN( OUTPUT,'  INVALID  WRITE  DIRECT  ') 

ELSE  IF  STATUS  -  'LDnn'  THEN 

WRITELN( OUTPUT,'  LOADER  ERROR  ') 

ELSE  IF  STATUS  -  'LOAD'  THEN 

WRITELN( OUTPUT,'  VAR  ENTRY  FILE  LOADED  BEYOND  CYL.  LOAD  LIMIT  ') 
ELSE  IF  STATUS  »  'LOCK'  THEN 

WRITELN( OUTPUT,'  DATA  SET  LOCKED  (F)  ') 

ELSE  IF  STATUS  -  'LGER'  THEN 

WRITELN( OUTPUT,'  LOGGING  I/O  ERROR  (F)  ') 

ELSE  IF  STATUS  -  'LGNA'  THEN 

WRITELN( OUTPUT,'  LOG  FILE  NOT  ACTIVE  ') 

ELSE  IF  STATUS  -  'LSZE'  THEN 

WRITELN( OUTPUT,'  LOG  SIZE  ERROR  ') 

ELSE  IF  STATUS  =  'MFNF'  THEN 

WRITELN( OUTPUT,'  MASTER  FILE  NOT  FOUND  ') 

ELSE  IF  STATUS  =  'MLNF'  THEN 

WRITELN( OUTPUT,'  MASTER  LINK  NOT  FOUND  ') 

ELSE  IF  STATUS  -  'MRNF'  THEN 

WRITELN( OUTPUT,'  MASTER  RECORD  NOT  FOUND  ') 

ELSE  IF  STATUS  =  'NHLD'  THEN 

WRITELN( OUTPUT,'  RECORD  NOT  HELD  ') 

ELSE  IF  STATUS  =  'NLAT'  THEN 

WRITELN( OUTPUT, '  NO  LOGGING  ATTACH  ') 

ELSE  IF  STATUS  =*  'NOIO'  THEN 

WRITELN( OUTPUT,'  NO  ASSIGNED  I/O  AREA  (F)  ') 

ELSE  IF  STATUS  =>  'NOTO'  THEN 

WRITELN( OUTPUT,'  TOTAL  NOT  AVAILABLE  ') 

ELSE  IF  STATUS  *  'NRCV'  THEN 

WRITELN( OUTPUT,'  NO  RECOVERY  MODE  ') 

ELSE  IF  STATUS  -  'NSMR'  THEN 

WRITELN( OUTPUT,'  NO  SECONDARY  MASTER  RECORD  FOUND  ') 

ELSE  IF  STATUS  -  'PNUL'  THEN 

WRITELN( OUTPUT,'  POSSIBLE  NULL  RECORD  ') 

ELSE  IF  STATUS  -  'POOL'  THEN 

WRITELN( OUTPUT,'  INSUFFICIENT  POOL  AREA  ') 

ELSE  IF  STATUS  -  'QFUL'  THEN 

WRITELN( OUTPUT,'  RESERVATION  QUEUE  IS  FULL  ') 

ELSE  IF  STATUS  -  'RSVD'  THEN 


WRITELN( OUTPUT,'  RESERVED  DATA  SET  ') 

ELSE  IF  STATUS  =  'SEND'  THEN 

WRITELN( OUTPUT,'  AN  ERROR  OCCURRED  ON  SENDING  THE  DATA  ') 
ELSE  IF  STATUS  =■  'TFUL'  THEN 

WRITELN( OUTPUT,'  TASK  TABLE  IS  FULL  ') 

ELSE  IF  STATUS  -  'UACM'  THEN 

WRITELN( OUTPUT,'  UNDEFINED  ACCESS  MODE  (F)  ') 

ELSE  IF  STATUS  -  'UCTL'  THEN 

WRITELN( OUTPUT,'  UNEQUAL  CONTROL  FIELD  ') 

ELSE  IF  STATUS  -  'ULGO'  THEN 

WRITELN< OUTPUT,'  UNDEFINED  LOGGING  OPTIONS  (F)  ') 

ELSE  IF  STATUS  -  'UPDE'  THEN 

WRITELN( OUTPUT,'  UPDATE  MODE  ERROR  ') 

ELSE  IF  STATUS  =*  'VMRE'  THEN 

WRITELN( OUTPUT,'  VARIABLE  READ  MASTER  ERROR  (F)  ') 

ELSE  WRITELN( OUTPUT,'  UNDEFINED  ERROR  CODE  '); 

WRITELN( OUTPUT); 

WAIT( 500) ; 

END;  (*OUTPUTERROR* ) 


BEGIN 

IF  STATUS  =  '****'  THEN 
OK  :=  TRUE 
ELSE  BEGIN 

OK  :=*  FALSE; 

OUTPUTERROR  (STATUS); 

WRITE  (',  HIT  RETURN  TO  CONTINUE  '); 
READLN 

END 

END  {*  CHECKSTATUS  *} ; 
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{ ************************************************************************ } 


{*  DATE:  23/05/85  *} 
{*  NAME:  SIGNONOROFF  *} 
{*  DESCRIPTION:  THIS  MODULE  LOADS  THE  DATABASE  SCHEMA  DEPENDING  *} 
{*  UPON  THE  USERS  REQUEST  AND  SIGNS  ON  OR  OFF  OF  THE  *} 
{*  DATABASE.  *} 
{*  *} 
{*  GLOBAL  VARIABLES  USED:  NONE  *} 
{*  GLOBAL  VARIABLES  CHANGED:  NONE  *} 
{*  MODULES  CALLED:  DATBAS , CHECKSTATUS  *} 
{*  CALLING  MODULES:  MAIN  *} 
{*  AUTHOR:  CAPT  DAVID  A.  GAITROS  *} 
{*  *} 


PROCEDURE  SIGNONOROFF(  ONOROFF  :  BUFF5 ;  DATABASE:  BUFF4) ; 
CONST 

FACT1  -  ' SECTIONSAFITDBUPDATENLFACTPRIVXXXXDEPTPRIVXXXX' ; 
FACT2  =  'STDTSHREXXXXTHESSHREXXXXSECTSHREXXXXMCRSSHREXXXX' 
FACT 3  =  'MQTRSHREXXXXMBKTSHREXXXXMORDSHREXXXXTIMESHREXXXX' 
FACT4  =  'BLRMSHREXXXXCPTYSHREXXXXDAYSSHREXXXXMSSFSHREXXXX' 
FACT 5  *  'MDEGSHREXXXXVEDUPRIVXXXXFSOCPRIVXXXXFCMTPRIVXXXX' 
FACT6  -  'VHAWPRIVXXXXFINTPRIVXXXXFCOMPRIVXXXXFTDYPRIVXXXX' 
FACT7  =  'CRSEPRIVXXXXTHTLPRIVXXXXSECLPRIVXXXXVCQRPRIVXXXX' 
FACT8  *  ' VREQPRIVXXXXVCBKPR IVXXXXVNMOPRIVXXXXS  CHDPRI VXXXX' 
FACT9  -  'CLSRPRIVXXXXTCMFPRIVXXXXFADVPRIVXXXXVINSPRIVXXXX' 
FACTION  'TADVPRIVXXXXVPDQPRIVXXXXVMSSPRIVXXXXEND. 

STDT1  =  ' SECTIONSAFITDBUPDATENLFACTSHREXXXXDEPTSHREXXXX' ; 
STDT2  =  ' STDTPRIVXXXXTHESSHREXXXXSECTPRIVXXXXMCRSSHREXXXX' 
STDT3  =  'MQTRSHREXXXXMBKTSHREXXXXMORDSHREXXXXTIMESHREXXXX' 
STDT4  *  'BLRMSHREXXXXCPTYSHREXXXXDAYSSHREXXXXMSSFSHREXXXX' 
STDT5  =  'MDEGSHREXXXXVEDUPRIVXXXXFSOCPRIVXXXXFCMTPRIVXXXX' 
STDT6  *  'VHAWPRIVXXXXFINTPRIVXXXXFCOMPRIVXXXXFTDYPRIVXXXX' 
STDT7  =  'CRSEPRIVXXXXTHTLPRIVXXXXSECLPRIVXXXXVCQRPRIVXXXX' 
STDT8  =  'VREQPRIVXXXXVCBKPRIVXXXXVNMOPRIVXXXXSCHDPRIVXXXX' 
STDT9  =  'CLSRPRIVXXXXTCMFPRIVXXXXFADVPRIVXXXXVINSPRIVXXXX' 
STDT10-  'TADVPRIVXXXXVPDQPRIVXXXXVMSSPRIVXXXXEND. 


MCRS1  =  'SECTIONSAFITDBUPDATENLFACTSHREXXXXDEPTSHREXXXX'; 
MCRS2  =  'STDTSHREXXXXTHESSHREXXXXSECTSHREXXXXMCRSPRIVXXXX' 
MCRS3  =»  'MQTRPRIVXXXXMBKTPRIVXXXXMORDPRIVXXXXTIMEPRIVXXXX' 
MCRS4  =  ' BLRMPRIVXXXXCPTYPRIVXXXXDAYSPRIVXXXXMSSFSHREXXXX' 
MCRS5  =  'MDEGSHREXXXXVEDUPRIVXXXXFSOCPRIVXXXXFCMTPRIVXXXX' 
MCRS6  =  'VHAWPRIVXXXXFINTPRIVXXXXFCOMPRIVXXXXFTDYPRIVXXXX' 
MCRS7  =  'CRSEPRIVXXXXTHTLPRIVXXXXSECLPRIVXXXXVCQRPRIVXXXX' 
MCRS8  =  'VREQPRIVXXXXVCBKPRIVXXXXVNMOPRIVXXXXSCHDPRIVXXXX' 
MCRS9  =  'CLSRPRIVXXXXTCMFPRIVXXXXFADVPRIVXXXXVINSPRIVXXXX' 
MCRS10*  'TADVPRIVXXXXVPDQPRIVXXXXVMSSPRIVXXXXEND. 


THES1  =  'SECTIONSAFITDBUPDATENLFACTSHREXXXXDEPTSHREXXXX'; 
THES2  -  'STDTSHREXXXXTHESPRIVXXXXSECTSHREXXXXMCRSSHREXXXX'; 
THES3  =  'MQTRSHREXXXXMBKTSHREXXXXMORDSHREXXXXTIMESHREXXXX' ; 


{* 

46 

*} 

{* 

48 

*} 

{* 

48 

*} 

{* 

48 

*} 

{* 

48 

*} 

{* 

48 

*} 

{* 

48 

*} 

{* 

48 

*} 

{* 

48 

*} 

{* 

48 

*} 

{* 

46 

*} 

{* 

48 

*} 

{* 

48 

*} 

{* 

48 

*} 

{* 

48 

*} 

{* 

48 

*} 

{* 

48 

*} 

{* 

48 

*} 

{* 

48 

*} 

{* 

48 

*} 

{* 

46 

*} 

{* 

48 

*} 

{* 

48 

*} 

{* 

48 

*} 

{* 

48 

*} 

{* 

48 
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{* 

48 

*} 

{* 

48 

*} 

{* 

48 

*} 

{* 

48 

*} 

{* 

46 

*} 

{* 

48 

*} 

{* 

00 

*} 
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THES4  =  'BLRMSHREXXXXCPTYSHREXXXXFINTSHREXXXXMSSFSHREXXXX' 
THES5  =  'MDEGSHREXXXXVEDUPRIVXXXXFSOCPRIVXXXXFCMTPRIVXXXX' 
THES6  =  'VHAWPRIVXXXXFINTPRIVXXXXFCOMPRIVXXXXFTDYPRIVXXXX' 
THES  7  =  'CRSEPRIVXXXXTHTLPRIVXXXXSECLPRIVXXXXVCQRPRIVXXXX' 
THES8  =  'VREQPRIVXXXXVCBKPRIVXXXXVNMOPRIVXXXXSCHDPRIVXXXX' 
THES9  =  'CLSRPRIVXXXXTCMFPRIVXXXXFADVPRIVXXXXVINSPRIVXXXX' 
THES10=  'TADVPRIVXXXXVPDQPRIVXXXXVMSSPRIVXXXXEND. 


{*  48  *} 
{*  48  *} 
{*  48  *} 
{*  48  *} 
{*  48  *} 
{*  48  *} 
{*  48  *} 


MSSF1  = 
MSSF2  = 
MSSF3  = 
MSSF4  = 
MSSF5  = 
MSSF6  = 
MSSF7  = 
MSSF8  = 
MSSF9  = 
MSSF10- 


' SECTIONS AFITDBUPDATENLFACTSHREXXXXDEPTSHREXXXX' ; 

'STDTSHREXXXXTHESSHREXXXXSECTSHREXXXXMCRSSHREXXXX' 

'MQTRSHREXXXXMBKTSHREXXXXMORDSHREXXXXTIMESHREXXXX' 

'BLRMSHREXXXXCPTYSHREXXXXFINTSHREXXXXMSSFPRIVXXXX' 

'MDEGPRIVXXXXVEDUPRIVXXXXFSOCPRIVXXXXFCMTPRIVXXXX' 

'VHAWPRIVXXXXDAYSPRIVXXXXFCOMPRIVXXXXFTDYPRIVXXXX' 

'CRSEPRIVXXXXTHTLPRIVXXXXSECLPRIVXXXXVCQRPRIVXXXX' 

'VREQPRIVXXXXVCBKPRIVXXXXVNMOPRIVXXXXSCHDPRIVXXXX' 

'CLSRPRIVXXXXTCMFPRIVXXXXFADVPRIVXXXXVINSPRIVXXXX' 

'TADVPRIVXXXXVPDQPRIVXXXXVMSSPRIVXXXXEND. 


{*  46  *} 
{*  48  *} 
{*  48  *} 
{*  48  *} 
{*  48  *} 
{*  48  *} 
{*  48  *} 
{*  48  *} 
{*  48  *} 
{*  48  *} 


TYPE 

BUFF46  =  PACKED  ARRAY  [1..46]  OF  CHAR; 

BUFF48  =  PACKED  ARRAY  [1..48]  OF  CHAR; 

VAR 

FUNCTIONS  :  8UFF5 ; 

SCHEMA:  BUFF480; 

ENDIT:  BUFF4 ; 

INDEX  :  INTEGER; 

OK  :  BOOLEAN; 

PROCEDURE  DATBAS  (%STDESCR  FUNCTIONS:  BUFF5 ;  STATUS  :  BUFF4 ; 

SCHEMA  :  BUFF480;  ENDIT:  BUFF4) ;  FORTRAN; 

BEGIN 

ENDIT  :=  'END.'; 

FUNCTIONS  :=  ONOROFF; 

IF  DATABASE  =  'FACT'  THEN 

SCHEMA  :=  FACT1  +  FACT2  +  FACT3  +  FACT4  +  FACT5  + 
FACT6  +  FACT7  +  FACT8  +  FACT9  +FACT10+  EXTRA2 
ELSE  IF  DATABASE  =  'STDT'  THEN 

SCHEMA  :=  STDT1  +  STDT2  +  STDT3  +  STDT4  +  STDT5  + 
STDT6  +  STDT7  +  STDT8  +  STDT9  +  STDT10  +  '  ' 

ELSE  IF  DATABASE  =  'MCRS'  THEN 

SCHEMA  :=  MCRS1  +  MCRS2  +  MCRS3  +  MCRS4  +  MCRS5  + 
MCRS6  +  MCRS7  +  MCRS8  +  MCRS9  +  MCRS 10+  EXTRA2 
ELSE  IF  DATABASE  =  'THES'  THEN 

SCHEMA  :=>  THES1  +  THES2  +  THES3  +  THES4  +  THES5  + 
THES6  +  THES7  +  THES8  +  THES9  +  THES 10+  EXTRA2 
ELSE  SCHEMA  :=  MSSF1  +  MSSF2  +  MSSF3  +  MSSF4  +  MSSF5  + 
MSSF6  +  MSSF7  +  MSSF8  +  MSSF9  +  MSSF10  +  EXTRA2 ; 
DATBAS ( FUNCTIONS , STATUS , SCHEMA , ENDIT) ; 

CHECKSTATUS(OK) ; 

IF  OK  THEN 
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SINON'  THEN 


IF  FUNCTIONS  -  ' 

BEGIN 
WRITELN; 

WRITELN; 

WRITELN(^THE  PROGRAM  IS  SIGNED  ON  TO  THE  DATABASE  '); 
WRITELN 
END 
ELSE 
BEGIN 

WRITELN; 

WRITELN; 

WRITELN('THE  PROGRAM  IS  SIGNED  OFF  OP  THE  DATABASE  '); 
WRITELN 

END 

ELSE 

BEGIN 

WRITELN; 

WRITELN; 

WRITELN(' DATABASE  ERROR,  DATABASE  IS  NOT  SIGNED  ON  ') 

END 


END;  (*SIGNONOROFF  *) 
{*  LAYER  5  *} 


{* 

DATE: 

01/08/85 

*} 

{* 

NAME: 

WRMSTDT 

*} 

{* 

DESCRIPTION:  THIS  MODULE  WRITES  A 

NEW 

STUDENT 

MASTER 

RECORD  TO 

*} 

{* 

THE  DATABASE.  THE  MODULE 

EXPECTS  THE 

RECORD 

TO  BE 

*} 

{* 

IN  THE  FORMAT  OF  THE  STDT_ 

_REC 

DATA  TYPE. 

*} 

{* 

*} 

{* 

FILES 

READ:  AFITDB 

*} 

{* 

FILES 

WRITTEN:  AFITDB 

*} 

{* 

GLOBAL 

VARIABLES  USED:  NONE 

*} 

{* 

GLOBAL 

VARIABLES  CHANGED:  NONE 

*} 

{* 

MODULES  CALLED:  CHECKSTATUS 

*} 

{* 

CALLING  MODULES: 

*} 

{* 

AUTHOR 

:  DAVID  A  GAITROS ,  CAPT,  USAF 

*} 

{* 

*} 

PROCEDURE  WRMSTDT  ( STDT : STDT_REC ) ; 
VAR 


FUNCTIONS:  BUFF5 ; 

DATASET 

BUFF4; 

SSAN 

BUFF9 ; 

ELEMENTS 

BUFF280; 

BUFFER 

BUFF408 ; 

ENDIT 

BUFF4; 

INDEX 

INTEGER; 

OK 

BOOLEAN; 

PROCEDURE  DATBAS(%STDESCR  FUNCTIONS:  BUFF5 ;  STATUS:  BUFF4 ;  DATASET:  BUFF4; 

SSAN:  BUFF9 ;  ELEMENTS:  BUFF280;  BUFFER: BUFF408 ;  ENDIT: BUFF4) ; 
FORTRAN; 


BEGIN 


FUNCTIONS  :=  'WRITM'; 

DATASET  :*  ' STDT' ; 

SSAN  :*  STDT. CTRL; 

ELEMENTS  :»  STDTC0NST1  +  STDTCONST2  +  STDTCONST3  +STDTCONST4  + 

,  STDTCONST5  +  STDTCONST6  +  STDTCONST7 ; 

FOR  INDEX  :»  1  TO  408  DO  BUFFER  [INDEX] 

ENDIT  :■  'END.'; 

WITH  STDT  DO  BEGIN 

BUFFER  :=  CTRL  +  SEQN  +  NAME  +  RANK  +  GRAD  +  SRVC  +  AERO  +  DORK  + 

DOCM  +  YRSS  +  SEXX  +  BOXN  +  DTSC  +  PMSC  +  ADDR  +  EADR  +  HMPH  + 

DTPH  +  EDCD  +  DOBH  +  POBH  +  MSTA  +  SPOS  +  SDOB  +  MSPS  +  NDEP  + 

RACE  +  RELN  +  LCMD  +  LORG  +  TITL  +  DURN  +  EXTRA  +  EXTRA  +  EXTRA; 

DATBAS  ( FUNCTIONS , STATUS , DATASET , SSAN , ELEMENTS , BUFFER , ENDIT ) ; 
CHECKSTATUS(OK) 

END 

END; 


{*  LAYER  5  *} 


{* 

DATE:  01/08/85 

*} 

{* 

NAME:  RDMFACT 

*} 

{* 

DESCRIPTION:  THIS  ROUTINE  READS  A  RECORD  FROM  THE 

STUDENT 

*} 

{* 

MASTER  FILE  AND  PUTS  THE  INFORMATION  INTO 

THE  RECORD 

*} 

{* 

FACT  OF  TYPE  FACT_REC; 

*} 

{* 

*} 

{* 

FILES  READ:  AFITDB 

*} 

{* 

FILES  WRITTEN:  NONE 

*} 

{* 

GLOBAL  VARIABLES  USED:  NONE 

*} 

{* 

GLOBAL  VARIABLES  CHANGED:  NONE 

*} 

{* 

MODULES  CALLED:  CHECKSTATUS 

*} 

{* 

CALLING  MODULES: 

*} 

{* 

AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF 

*} 

{* 

*} 

{ ************************************************************************ } 


PROCEDURE  RDMFACT  (VAR  FACT: FACT_REC) ; 
VAR 

FUNCTIONS:  BUFF5 ; 

DATASET  :  BUFF4; 

SSAN  :  BUFF9 ; 

ELEMENTS:  BUFF280; 

BUFFER  :  BUFF408 ; 

ENDIT  :  BUFF4; 

INDEX, I  :  INTEGER; 

OK  :  BOOLEAN; 


n 


1 

1 1 

?! 


i 


PROCEDURE  DATBAS( XSTDESCR  FUNCTIONS:  BUFF5;  STATUS:  BUFF4 ;  DATASET:  BUFF4 ; 

SSAN:  BUFF9 ;  ELEMENTS:  BUFF280;  BUFFER: BUFF408 ;  ENDIT: BUFF4) ; 
FORTRAN; 


BEGIN 


FUNCTIONS  :*  ' READM' ; 

DATASET  :-  'FACT'; 

SSAN  :-  FACT. CTRL; 

ELEMENTS  :*  FACTCONST1  +  FACTCONST2  +  FACTCONST3  +FACTCONST4  + 
FACTCONST5  +  FACTCONST6; 

FOR  INDEX  :*  1  TO  408  DO  BUFFER  [INDEX] 

ENDIT  :-  'END.'; 

DATBAS ( FUNCTIONS , STATUS , DATASET , SSAN , ELEMENTS , BUFFER , ENDIT) ; 
CHECK STATUS (OK) ; 

IF  OK  THEN  BEGIN 

WITH  FACT  DO  BEGIN 

FOR  I  :*  1  TO  9  DO  CTRL  [I]  :=  BUFFER  [I]; 


END; 

END; 


FOR  I  :=  1  TO  28  DO  NAME  [I]  :=  BUFFER  [1+9]; 
FOR  I  :=  1  TO  3  DO  RANK  [I]  :«  BUFFER  [1+37]; 


[*  LAYER  5  *} 
{ ************ 
{*  DATE: 
{*  NAME: 


DATE:  01/08/85  *} 

NAME:  ADMFACT  *} 

DESCRIPTION:  THIS  MODULE  ADDS  A  FACULTY  MASTER  RECORD  TO  THE  *} 

AFIT  DATABASE  SYSTEM  ASSUMING  THAT  THE  MEMBER  DOES  NOT  *} 
EXIT.  THE  INFORMATION  SHOULD  BE  IN  THE  RECORD  PASSED  *} 
TO  THE  MODULE  OF  TYPE  FACT  REC.  *} 

*} 

FILES  READ:  NONE  *} 

FILES  WRITTEN:  AFITDB  *} 

GLOBAL  VARIABLES  USED:  NONE  *} 


{*  GLOBAL  VARIABLES  CHANGED:  NONE  *} 
{*  MODULES  CALLED:  CHECKSTATUS  *} 
{*  CALLING  MODULES:  *} 
{*  AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF  *} 
{*  *} 


PROCEDURE  ADMFACT  ( FACT : FACT_REC ) ; 

VAR 

FUNCTIONS:  BUFFS; 

DATASET  :  BUFF4 ; 

SSAN  :  BUFF9 ; 

ELEMENTS:  BUFF280; 

BUFFER  :  BUFF408 ; 

ENDIT  :  BUFF4 ; 

INDEX  :  INTEGER; 

OK  :  BOOLEAN; 

PROCEDURE  DATBASUSTDESCR  FUNCTIONS:  BUFF5;  STATUS:  BUFF4 ;  DATASET:  BUFF4 ; 

SSAN:  BUFF9 ;  ELEMENTS:  BUFF280;  BUFFER :BUFF408;  ENDIT: BUFF4) ; 
FORTRAN; 

BEGIN 

FUNCTIONS  :»  'ADD-M'; 

DATASET  :«  'FACT'; 

SSAN  :-  FACT -CTRL; 

ELEMENTS  :=»  FACTCONST1  +  FACTCONST2  +  FACTCONST3  +FACTCONST4  + 
FACTCONST5  +  FACTCONST6  +  FACTCONST7 ; 

FOR  INDEX  :=■  1  TO  408  DO  BUFFER  [INDEX] 

ENDIT  :=  'END.'; 

WITH  FACT  DO  BEGIN 

BUFFER  : -CTRL+NAME+RANK+SRVC+DOCM+HDAT+SALR+DOBI+SEXX+AERO+DTSC 

+PMSC+DORK+YRSS+ADDR+HPHN+EADR+MSTA+SPOS+SDOB+NDEP+RACE+RELN+ 

OFIC+OPHN+LORG+TITL+DEPT+EXTRA+EXTRA+EXTRA; 

DATBAS  ( FUNCTIONS , STATUS .DATASET , SS AN , ELEMENTS , BUFFER , ENDIT) ; 
CHECKSTATUS (OK) 


END 


{* 

{ ki 

{* 

LAYER  5  *} 

L-t-  lr  A- -A- -lr  A~-| 

Hr} 

*} 

DATE:  01/08/85 

{* 

NAME:  WRMFACT 

*} 

{* 

DESCRIPTION:  THIS  MODULE  UPDATES  A  FACULTY 

MASTER 

RECORD 

TO  THE 

*} 

{* 

AFIT  DATABASE  SYSTEM  ASSUMING  THAT 

THE  MEMBER  DOES 

*} 

{* 

EXIST.  THE  INFORMATION  SHOULD  BE 

IN  THE 

RECORD 

PASSED 

*} 

{* 

TO  THE  MODULE  OF  TYPE  FACT  REC. 

*} 

{* 

*} 

{* 

FILES  READ:  NONE 

*} 

(* 

FILES  WRITTEN:  AFITDB 

*} 

{* 

GLOBAL  VARIABLES  USED:  NONE 

*} 

{* 

GLOBAL  VARIABLES  CHANGED:  NONE 

*} 

{* 

MODULES  CALLED:  CHECKSTATUS 

*} 

[* 

CALLING  MODULES: 

*} 

{* 

AUTHOR:  DAVID  A  GAITROS,  CAPT,  USAF 

*} 

{* 

*} 

{** 

r*1rk***irk**irk*k********k************1rlrk********iei 

.  «.  i.  i..i-  i.  i.  i 

rxxwxxx'j 

§»■■■■• 
nnrmr  mn 

r  ******i 

Hr} 

PROCEDURE  ADMFACT  ( FACT : FACT_REC ) ; 
VAR 


FUNCTIONS:  BUFF5; 

DATASET 

BUFF4; 

SSAN 

BUFF9 ; 

ELEMENTS 

BUFF280; 

BUFFER 

BUFF408 ; 

ENDIT 

BUFF4 ; 

INDEX 

INTEGER; 

OK 

BOOLEAN; 

PROCEDURE  DATBAS ( ZSTDESCR  FUNCTIONS:  BUFF 5 ;  STATUS:  BUFF4;  DATASET:  BUFF4; 

SSAN:  BUFF9 ;  ELEMENTS:  BUFF280;  BUFFER: BUFF408 ;  ENDIT: BUFF4) ; 
FORTRAN; 


BEGIN 


FUNCTIONS  :=  'WRITM' ; 

DATASET  :=  'FACT'; 

SSAN  :»  FACT. CTRL; 

ELEMENTS  :=  FACTCONST1  +  FACTCONST2  +  FACTCONST3  +FACTCONST4  + 
FACTCONST5  +  FACTCONST6  +  FACTCONST7 ; 

FOR  INDEX  :=■  1  TO  408  DO  BUFFER  [INDEX]  :=  '  '; 

ENDIT  :*  'END.'; 

WITH  FACT  DO  BEGIN 

BUFFER  :-CTRL+NAME+RANK+SRVC+DOCM+HDAT+SALR+DOBI+SEXX+AERO+DTSC 

+PMSC+DORK+YRSS+ADDR+HPHN+EADR+MSTA+SPOS+SDOB+NDEP+RACE+RELN+ 

OFIC+OPHN+LORG+TITL+DEPT+EXTRA+EXTRA+EXTRA; 

DATBAS  ( FUNCTIONS , STATUS .DATASET , SSAN , ELEMENTS , BUFFER , ENDIT) ; 
CHECKSTATUS(OK) 


END 


{*  LAYER  5  *} 
{*  DATE: 


DATE:  01/08/85 
NAME:  RDMSTDT 

DESCRIPTION:  THIS  ROUTINE  READS  A  RECORD  FROM  THE  STUDENT 

MASTER  FILE  AND  PUTS  THE  INFORMATION  INTO  THE  RECORD 
STDT  OF  TYPE  STDT_REC; 

FILES  READ:  AFITDB 
FILES  WRITTEN:  NONE 
GLOBAL  VARIABLES  USED:  NONE 
GLOBAL  VARIABLES  CHANGED:  NONE 
MODULES  CALLED:  CHECKSTATUS 
CALLING  MODULES: 

AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF 


PROCEDURE  RDMSTDT  (VAR  STDT : STDT_REC ) ; 
VAR 


FUNCTIONS 

:  BUFF5; 

DATASET  : 

BUFF4; 

SSAN  : 

BUFF9 ; 

ELEMENTS : 

BUFF280 

BUFFER  : 

BUFF408 

ENDIT 

BUFF4; 

INDEX  : 

INTEGER 

OK  : 

BOOLEAN 

PROCEDURE  DATBAS ( %STDESCR  FUNCTIONS:  BUFF5;  STATUS:  BUFF4 ;  DATASET:  BUFF4 ; 

SSAN:  BUFF9 ;  ELEMENTS:  BUFF280;  BUFFER: BUFF408 ;  ENDIT : BUFF4) ; 
FORTRAN; 


SB 


FUNCTIONS  ' READM' ; 

DATASET  :»  ' STDT' ; 

SSAN  :»  STDT . CTRL ; 

ELEMENTS  STDTCONST1  +  STDTCONST2  +  STDTCONST3  +STDTCONST4  + 
STDTCONST5  +  STDTCONST6  +  STDTCONST7 ; 

FOR  INDEX  1  TO  408  DO  BUFFER  [INDEX] 

ENDIT  'END.'; 

DATBAS( FUNCTIONS .STATUS .DATASET, SSAN .ELEMENTS .BUFFER, ENDIT) ; 
CHECKSTATUS(OK); 

IF  OK  THEN  BEGIN 

WITH  STDT  DO  BEGIN 

FOR  INDEX  1  TO  6  DO  BEGIN 

DOCM  [INDEX]  :=  BUFFER  [INDEX  +  62]; 

DORK  [INDEX]  :*  BUFFER  [INDEX  +  56]; 

DTSC  [INDEX]  BUFFER  [INDEX  +  75]; 

PMSC  [INDEX]  :=»  BUFFER  [INDEX  +  81]; 

DOBH  [INDEX]  :=  BUFFER  [INDEX  +  186]; 

SDOB  [INDEX]  :*  BUFFER  [INDEX  +  245] 

END; 

FOR  INDEX  1  TO  40  DO  BEGIN 

ADDR  [INDEX]  :«  BUFFER  [INDEX  +87]; 

EADR  [INDEX]  BUFFER  [INDEX  +  127]; 

POBH  [INDEX]  :«  BUFFER  [INDEX  +  192] 

END; 

FOR  INDEX  :*  1  TO  50  DO  BEGIN 

LORG  [INDEX]  :  =  BUFFER  [INDEX  +  313]; 

TITL  [INDEX]  :=  BUFFER  [INDEX  +363] 

END; 

FOR  INDEX  :*  1  TO  2  DO  BEGIN 

SRVC  [INDEX]  :=  BUFFER  [INDEX  +  45]; 

YRSS  [INDEX]  :=»  BUFFER  [INDEX  +  68]; 

NDEP  [INDEX]  :=  BUFFER  [INDEX  +  252]; 

RACE  [INDEX]  :=*  BUFFER  [INDEX  +  254]; 

RELN  [INDEX]  :=  BUFFER  [INDEX  +  256]; 

DURN  [INDEX]  :=  BUFFER  [INDEX  +  363] 

END; 

FOR  INDEX  1  TO  7  DO  BEGIN 

HMPH  [INDEX]  :=  BUFFER  [INDEX  +  167]; 

DTPH  [INDEX]  :*  BUFFER  [INDEX  +  174] 

END; 

FOR  INDEX  :*  1  TO  5  DO  BEGIN 

EDCD  [INDEX]  :=  BUFFER  [INDEX  +  181]; 

LCMD  [INDEX]  :=  BUFFER  [INDEX  +  258] 

END; 

FOR  INDEX  :*  1  TO  3  DO  BEGIN 

SEQN  [INDEX]  :»  BUFFER  [INDEX  +  9]; 

RANK  [INDEX]  BUFFER  [INDEX  +  40] 

END; 

FOR  INDEX  1  TO  4  DO  BEGIN 

BOXN  [INDEX]  BUFFER  [INDEX  +  71]; 

NAME  [INDEX]  BUFFER  [INDEX  +12]; 

AERO  [INDEX]  :»  BUFFER  [INDEX  +  46] ; 

SPOS  [INDEX]  :«  BUFFER  [INDEX  +  233]; 


CTRL  [INDEX]  :=  BUFFER  [INDEX] 

END; 

AERO  [10]  :=  BUFFER  [57]; 

FOR  INDEX  5  TO  9  DO  BEGIN 

NAME  [INDEX]  :=  BUFFER  [INDEX  +12]; 
SPOS  [INDEX]  :=  BUFFER  [INDEX  +  2331 
CTRL  [INDEX]  :=  BUFFER  [INDEX] 

END; 

FOR  INDEX  :«  10  TO  12  DO  BEGIN 

NAME  [INDEX]  :=  BUFFER  [INDEX  +  12]; 
SPOS  [INDEX]  :*  BUFFER  [INDEX  +  233] 
END; 

FOR  INDEX  13  TO  28  DO 

NAME  [INDEX]  :=  BUFFER  [INDEX  +  12]; 
SEXX  :=  BUFFER  [70]; 

MSTA  :*  BUFFER  [232]; 

MSPS  :=  BUFFER  [251] 


END 


{ ************************************************************************ } 


{* 

DATE:  01/08/85 

*} 

{* 

NAME:  ADMSTDT 

*} 

{* 

DESCRIPTION:  THIS  MODULE  ADDS  A  STUDENT  MASTER 

RECORD  TO  THE 

*} 

{* 

AFIT  DATABASE  SYSTEM  ASSUMING  THAT  THE 

STUDENT  DOES  NOT 

+  1 

"  ) 

{* 

EXIT.  THE  INFORMATION  SHOULD  BE  IN  THE  RECORD  PASSED 

*} 

{* 

TO  THE  MODULE  OF  TYPE  STDT  REC. 

*} 

{* 

*} 

{* 

FILES  READ:  NONE 

*} 

{* 

FILES  WRITTEN:  AFITDB 

*} 

{* 

GLOBAL  VARIABLES  USED:  NONE 

*} 

{* 

GLOBAL  VARIABLES  CHANGED:  NONE 

*} 

{* 

MODULES  CALLED:  CHECKSTATUS 

*} 

{* 

CALLING  MODULES: 

*} 

{* 

AUTHOR:  DAVID  A  GAITROS,  CAPT,  USAF 

*} 

{* 

*} 

PROCEDURE  ADMSTDT  ( STDT : STDT_REC) ; 
VAR 


FUNCTIONS:  BUFF5 ; 

DATASET 

BUFF4; 

SSAN 

BUFF9 ; 

ELEMENTS 

BUFF280; 

BUFFER 

BUFF408 ; 

ENDIT 

BUFF4 ; 

INDEX 

INTEGER; 

OK 

BOOLEAN; 

PROCEDURE  DATBAS ( ZSTDESCR  FUNCTIONS:  BUFF5 ;  STATUS:  BUFF4 ;  DATASET:  BUFF4; 

SSAN:  BUFF9 ;  ELEMENTS:  BUFF280;  BUFFER: BUFF408 ;  ENDIT: BUFF4) ; 
FORTRAN; 

BEGIN 

FUNCTIONS  :=  'ADD-M'; 

DATASET  :=  'STDT'; 

SSAN  :  =  STDT. CTRL; 

ELEMENTS  :=  STDTCONST1  +  STDTCONST2  +  STDTCONST3  +STDTCONST4  + 
STDTCONST5  +  STDTCONST6  +  STDTCONST7 ; 

FOR  INDEX  :=  1  TO  408  DO  BUFFER  [INDEX]  :=  '  '; 

ENDIT  :=*  'END.'; 

WITH  STDT  DO  BEGIN 

BUFFER  :=  CTRL  +  SEQN  +  NAME  +  RANK  +  GRAD  +  SRVC  +  AERO  +  DORK  + 

DOCM  +  YRSS  +  SEXX  +  BOXN  +  DTSC  +  PMSC  +  ADDR  +  EADR  +  HMPH  + 

DTPH  +  EDCD  +  DOBH  +  POBH  +  MSTA  +  SPOS  +  SDOB  +  MSPS  +  NDEP  + 

RACE  +  RELN  +  LCMD  +  LORG  +  TITL  +  DURN  +  EXTRA  +  EXTRA  +  EXTRA 

DATBAS  ( FUNCTIONS , STATUS , DATASET , SSAN , ELEMENTS , BUFFER , ENDIT) ; 
CHECKSTATUS(OK) 

END 

END; 
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{* 

DATE:  01/08/85 

*} 

{* 

NAME:  WRMSTDT 

*} 

{* 

DESCRIPTION:  THIS  MODULE  WRITES  A  STUDENT 

1  MASTER  RECORD  TO  THE 

*} 

{* 

AFIT  DATABASE  SYSTEM  ASSUMING  THAT  THE  STUDENT  DOES  NOT 

*} 

{* 

EXIT.  THE  INFORMATION  SHOULD  BE 

IN  THE  RECORD  PASSED 

*} 

{* 

TO  THE  MODULE  OF  TYPE  STDT  REC. 

THIS  MODULE  ASSSUMES 

*} 

{* 

THE  RECORD  ALREADY  EXISTS  ON  THE 

DATABASE  SYSTEM 

*} 

{* 

*} 

{* 

FILES  READ:  NONE 

*} 

{* 

FILES  WRITTEN:  AFITDB 

*} 

{* 

GLOBAL  VARIABLES  USED:  NONE 

*} 

{* 

GLOBAL  VARIABLES  CHANGED:  NONE 

*} 

{* 

MODULES  CALLED:  CHECKSTATUS 

*} 

{* 

CALLING  MODULES: 

*} 

{* 

AUTHOR:  DAVID  A  GAITROS,  CAPT,  USAF 

*} 

{* 

*} 

PROCEDURE  WRMSTDT  ( STDT : STDT_REC ) ; 

VAR 

FUNCTIONS:  BUFF5 ; 

DATASET  :  BUFF4; 

SSAN  :  BUFF9 ; 

ELEMENTS:  BUFF280; 

BUFFER  :  BUFF408 ; 

ENDIT  :  BUFF4; 

INDEX  :  INTEGER; 

OK  :  BOOLEAN; 

PROCEDURE  DATBAS ( ZSTDESCR  FUNCTIONS:  BUFF5 ;  STATUS:  BUFF4;  DATASET:  BUFF4 ; 

SSAN:  BUFF9 ;  ELEMENTS:  BUFF280;  BUFFER: BUFF408 ;  ENDIT: BUFF4) ; 
FORTRAN; 

BEGIN 

FUNCTIONS  :=  ' WRITM' ; 

DATASET  : =  ' STDT' ; 

SSAN  :=  STDT. CTRL; 

ELEMENTS  :=  STDTCONST1  +  STDTCONST2  +  STDTCONST3  +STDTCONST4  + 
STDTCONST5  +  STDTCONST6  +  STDTCONST7 ; 

FOR  INDEX  :=  1  TO  408  DO  BUFFER  [INDEX]  :=  '  '; 

ENDIT  :=  'END.'; 

WITH  STDT  DO  BEGIN 

BUFFER  :=■  CTRL  +  SEQN  +  NAME  +  RANK  +  GRAD  +  SRVC  +  AERO  +  DORK  + 

DOCM  +  YRSS  +  SEXX  +  BOXN  +  DTSC  +  PMSC  +  ADDR  +  EADR  +  HMPH  + 

DTPH  +  EDCD  +  DOBH  +  POBH  +  MSTA  +  SPOS  +  SDOB  +  MSPS  +  NDEP  + 

RACE  +  RELN  +  LCMD  +  LORG  +  TITL  +  DURN  +  EXTRA  +  EXTRA  +  EXTRA 

DATBAS  ( FUNCTIONS , STATUS , DATASET , SSAN , ELEMENTS , BUFFER , ENDIT) ; 
CHECKSTATUS(OK) 

END 

END; 
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{♦A**********************************************************************} 


{* 

DATE:  02/08/85 

*} 

{* 

NAME:  WRMSECT 

*} 

{* 

DESCRIPTION:  THIS  MODULE  WRITES  AN  UPDATED  RECORD  BACK 

TO  THE 

*} 

{* 

MASTER  SECTION  FILE  OF  THE  AFIT  DATABASE.  THE 

INFO  IS 

*} 

{* 

PASSED  TO  THE  MODULE  VIA  THE  SECT_REC  RECORD. 

*} 

{* 

*} 

{* 

FILES  READ:  NONE 

*} 

{* 

FILES  WRITTEN:  AFITDB 

*} 

{* 

GLOBAL  VARIABLES  USED:  NONE 

*} 

{* 

GLOBAL  VARIABLES  CHANGED:  NONE 

*} 

{* 

MODULES  CALLED:  CHECKSTATUS 

*} 

{* 

CALLING  MODULES: 

*} 

{* 

AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF 

*} 

{* 

*} 

PROCEDURE  WRMSECT  (SECT:SECT_REC) ; 
VAR 


FUNCTIONS:  BUFF5 ; 

DATASET 

BUFF4 ; 

CODE 

BUFF8 ; 

ELEMENTS 

BUFF80 ; 

BUFFER 

BUFF40 ; 

ENDIT 

BUFF4; 

INDEX 

INTEGER 

OK 

BOOLEAN 

PROCEDURE  DArBAS(%STDESCR  FUNCTIONS:  BUFF 5;  STATUS:  BUFF4 ;  DATASET:  BUFF4; 

CODE:  BUFF8 ;  ELEMENTS:  BUFF80;  BUFFER :BUFF40;  ENDIT: BUFF4) ; 
FORTRAN; 


BEGIN 


FUNCTIONS  :=  ' WRITM' ; 

DATASET  :=  'SECT'; 

CODE  :=  SECT. CTRL; 

ELEMENTS  :=  SECTCONST1+SECTCONST2 ; 

FOR  INDEX  :=  1  TO  40  DO  BUFFER  [INDEX]  :=  '  '; 

ENDIT  :=  'END.'; 

WITH  SECT  DO  BEGIN 

BUFFER  :=  CTRL+LSSN+GRDT+ENDT+NRSN+ EXTRA; 

DATBAS( FUNCTIONS , STATUS .DATASET , CODE , ELEMENTS , BUFFER , ENDIT) ; 
CHECKSTATUS(OK) ; 


END 


FILES 

FILES 


{★★A*********************************************************************} 

{* 

{* 

{* 

{* 
t* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{’ 

PROCEDURE  RDMSECT( VAR  SECT:SECT_REC;  CODE:BUFF8); 

VAR 


DATE:  02/08/85  *} 

NAME:  RDMSECT  *} 

DESCRIPTION:  THIS  MODULE  READS  A  RECORD  FROM  THE  MASTER  SECTION  *} 
FILE  OF  THE  AFIT  DATABASE  AND  FORMATS  THE  SECT_REC  *} 

RECORD  WITH  THE  INFORMATION.  *} 

*} 

READ:  AFITDB  *} 

WRITTEN:  NONE  *} 

GLOBAL  VARIABLES  USED:  NONE  *} 

GLOBAL  VARIABLES  CHANGED:  NONE  *} 

MODULES  CALLED:  CHECKSTATUS  *} 

CALLING  MODULES:  *} 

AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF  *} 

*} 


FUNCTIONS:  BUFF5 ; 

DATASET  :  BUFF4; 

ELEMENTS:  BUFF80; 

BUFFER  :  BUFF40 ; 

END IT  :  BUFF4 ; 

INDEX  :  INTEGER; 

OK  :  BOOLEAN; 

PROCEDURE  DATBASUSTDESCR  FUNCTIONS:  BDFF5 ;  STATUS:  BUFF4 ;  DATASET:  BUFF4; 

CODE:  BUFF8 ;  ELEMENTS:  BUFF80;  BUFFER: BUFF40;  ENDIT: BUFF4) ; 
FORTRAN; 

BEGIN 

FUNCTIONS  :=  'READM'; 

DATASET  :=  'SECT'; 

CODE  :=  SECT. CTRL; 

ELEMENTS  :=  SECTCONST1+SECTCONST2 ; 

FOR  INDEX  :=  1  TO  40  DO  BUFFER  [INDEX]  :=  '  '; 

ENDIT  :="  'END.'; 

WITH  SECT  DO  BEGIN 

DATBAS( FUNCTIONS, STATUS, DATASET, CODE, ELEMENTS, BUFFER, ENDIT); 
CHECKSTATUS (OK) ; 

IF  OK  THEN  BEGIN 

FOR  INDEX  :=  1  TO  3  DO  BEGIN 

CTRL  [INDEX]  :=  BUFFER  [INDEX]; 

LSSN  [INDEX]  :=  BUFFER  [INDEX  +  9]; 

GRDT  [INDEX]  :=  BUFFER  [INDEX  +  18]; 

ENDT  [INDEX]  :=  BUFFER  [INDEX  +  24]; 

NRSN  [INDEX]  :=  BUFFER  [INDEX  +  30] 

END; 

FOR  INDEX  :*  4  TO  6  DO  BEGIN 

CTRL  [INDEX]  :=  BUFFER  [INDEX]; 

LSSN  [INDEX]  :=  BUFFER  [INDEX  +9]; 

GRDT  [INDEX]  :=  BUFFER  [INDEX  +  18] ; 

ENDT  [INDEX]  :=  BUFFER  [INDEX  +  24] ; 


V » 


rY 


i************************************************************************ } 


{* 

t* 

{* 

{* 

t* 

t* 

t* 

{* 

{* 

{* 

i* 

{* 

i* 

{* 


DATE:  02/08/85 
NAME:  AD MSEC! 

DESCRIPTION:  THIS  MODULE  WRITES  AN  NEW  RECORD  BACK  TO  THE 

MASTER  SECTION  FILE  OF  THE  AFIT  DATABASE.  THE  INFO  IS 
PASSED  TO  THE  MODULE  VIA  THE  SECT_REC  RECORD. 

FILES  REAP:  NONE 
FILES  WRITTEN:  AFITDB 
GLOBAL  VARIABLES  USED:  NONE 
GLOBAL  VARIABLES  CHANGED:  NONE 
MODULES  CALLED:  CHECKSTATUS 
CALLING  MODULES: 

AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF 


*} 

*} 

*} 

*} 

*} 

*} 

*} 

*} 

*} 

*} 

*} 

*} 

*} 

*} 


{ *************************★**********************************************} 

PROCEDURE  ADMSECT  ( SECT: SECT_REC) ; 

VAR 


FUNCTIONS:  BUFF5 ; 
DATASET  :  BUFF4; 
CODE  :  BUFF8 ; 
ELEMENTS:  BUFF80; 
BUFFER  :  BUFF40 ; 
ENDIT  :  BUFF4; 
INDEX  :  INTEGER; 
OK  :  BOOLEAN; 


PROCEDURE  DATBASUSTDESCR  FUNCTIONS:  BUFF5;  STATUS:  8UFF4 ;  DATASET:  BUFF4; 

CODE:  BUFF8 ;  ELEMENTS:  BUFF80;  BUFFER :BUFF40;  ENDIT: BUFF4) ; 
FORTRAN ; 


BEGIN 

FUNCTIONS  :=  'ADD-M'; 

DATASET  :=  'SECT'; 

CODE  :=  SECT. CTRL; 

ELEMENTS  :=  SECTCONST1+SECTCONST2 ; 

FOR  INDEX  :=  1  TO  40  DO  BUFFER  [INDEX]  :=  '  '; 

ENDIT  :=  'END.'; 

WITH  SECT  DO  BEGIN 

BUFFER  :=  CTRL+LSSN+GRDT+ENDT+NRSN+EXTRA+EXTRA; 

DATBAS ( FUNCTIONS , STATUS , DATASET , CODE , ELEMENTS , BUFFER , ENDIT) ; 
CHECKSTATUS (OK) 

END 

END; 
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{*  DATE:  02/08/85  *} 

{*  NAME:  WRMMCRS  *} 

{*  DESCRIPTION:  THIS  MODULE  WRITES  AN  UPDATED  RECORD  TO  THE  *} 

{*  MASTER  COURSE  FILE  USING  THE  INFORMATION  PASSED  IN  *} 

{*  THE  MCRS  RECORD  OF  TYPE  MCRS  REC.  *} 

{*  *} 

{*  FILES  READ:  NONE  *} 

{*  FILES  WRITTEN:  AFITDB  *} 

{*  GLOBAL  VARIABLES  USED:  NONE  *} 

{*  GLOEAL  VARIABLES  CHANGED:  NONE  *} 

{*  MODULES  CALLED:  CHECKSTATUS  *} 

{*  CALLING  MODULES:  *} 

{*  AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF  *} 

{*  *} 

{ ********************************************  k********  *******  ************ } 

PROCEDURE  WRMMCRS  (MCRS: MCRS  REC); 


VAR 

FUNCTIONS:  BUFF5 ; 

DATASET  :  BUFF4; 

CODE  :  BUFF8 ; 

ELEMENTS:  BUFF80 ; 

BUFFER  :  BUFF80; 

ENDIT  :  BUFF4 ; 

INDEX  :  INTEGER; 

OK  :  BOOLEAN; 

PROCEDURE  DATBAS ( ZSTDESCR  FUNCTIONS:  BUFF5 ;  STATUS:  BUFF4;  DATASET:  BUFF4; 

CODE:  BUFF8 ;  ELEMENTS:  BUFF80 ;  BUFFER: BUFF80 ;  ENDIT: BUFF4) ; 
FORTRAN; 

BEGIN 

FUNCTIONS  :=  'WRITM'; 

DATASET  :=  'MCRS'; 

CODE  :=  MCRS. CTRL; 

ELEMENTS  :=  MCRSCONST1+MCRSCONST2 ; 

FOR  INDEX  :=  1  TO  80  DO  BUFFER  [INDEX]  :=  '  '; 

ENDIT  :=  'END.'; 

WITH  MCRS  DO  BEGIN 

BUFFER  :=  CTRL+CRHR+LCHR+LBHR+SZLM+TITL+REST+EXTRA+EXTRA; 

DATBAS ( FUNCTIONS , STATUS , DATASET , CODE , ELEMENTS , BUFFER , ENDIT) ; 
CHECKSTATUS (OK) 

END 


{* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{< 

PROCEDURE  RDMMCRS  (VAR  MCRS : MCRS_REC ) ; 
VAR 


DATE:  02/08/85 
NAME:  RDMMCRS 

DESCRIPTION:  THIS  ROUTINE  READS  A  MASTER  COURSE  RECORD  FROM 
THE  DATABASE  AND  FORMATS  THE  RECORD  MCRS  OF  TYPE 
MCRS_REC  WITH  THE  DATA  IF  THE  READ  WAS  ACCOMPLISHED. 

FILES  READ:  AFITDB 
FILES  WRITTEN:  NONE 
GLOBAL  VARIABLES  USED:  NONE 
GLOBAL  VARIABLES  CHANGED:  NONE 
MODULES  CALLED:  CHECKSTATUS 
CALLING  MODULES: 

AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF 


FUNCTIONS:  BUFF5 ; 

DATASET 

BUFF4; 

ELEMENTS 

BUFF80; 

BUFFER 

BUFF80 ; 

ENDIT 

BUFF4 ; 

INDEX 

INTEGER 

OK 

BOOLEAN 

CODE 

BUFF8 ; 

*} 

*} 

*} 

*} 

*} 

*} 

*} 

*} 

*} 

*} 

*} 

*} 

*} 

*} 


PROCEDURE  DATBAS ( ZSTDESCR  FUNCTIONS:  BUFF5 ;  STATUS:  BUFF4;  DATASET:  BUFF4 ; 

CODE:  BUFF8 ;  ELEMENTS:  BUFF80;  BUFFER :BUFF80;  ENDIT :BUFF4) ; 
FORTRAN; 


BEGIN 


FUNCTIONS  :=*  'RE ADM' ; 

DATASET  :*  'MCRS'; 

CODE  :=■  MCRS. CTRL; 

ELEMENTS  :=*  MCRSCONST1+MCRSCONST2 ; 

FOR  INDEX  :=  1  TO  80  DO  BUFFER  [INDEX]  :=  '  '; 

ENDIT  :=  'END.'; 

WITH  MCRS  DO  BEGIN 

DATBAS ( FUNCTIONS , STATUS , DATASET , CODE , ELEMENTS , BUFFER , END IT ) ; 
CHECKSTATUS(OK) ; 

IF  OK  THEN  BEGIN 

FOR  INDEX  :=  1  TO  8  DO  CTRL  [INDEX]  :=  BUFFER  [INDEX]; 

FOR  INDEX  :=  1  TO  50  DO  TITL  [INDEX]  :=  BUFFER  [INDEX  +13]; 
FOR  INDEX  :*  1  TO  2  DO  SZLM  [INDEX]  :=  BUFFER  [INDEX  +11]; 
CRHR  :=  BUFFER  [8]; 

LCHR  :*  BUFFER  [9]; 

LBHR  :=  BUFFER  [ 10] ; 

REST  :-  BUFFER  [63] 


END 


{* 

DATE:  02/08/85 

*} 

{* 

NAME:  ADMMCRS 

*} 

{* 

DESCRIPTION:  THIS  MODULE  ADDS  A  MASTER  RECORD  TO 

THE  COURSE 

*} 

{* 

MASTER  FILE  USING  THE  INFORMATION  PASSED 

IN  THE 

*1 

{* 

MCRS  RECORD  OF  TYPE  MCRS_REC. 

*) 

{* 

*} 

{* 

FILES  READ:  NONE 

*} 

{* 

FILES  WRITTEN:  NONE 

*} 

{* 

GLOBAL  VARIABLES  USED:  NONE 

*} 

{* 

GLOBAL  VARIABLES  CHANGED:  NONE 

*} 

{* 

MODULES  CALLED:  CHECKSTATUS 

*} 

{* 

CALLING  MODULES: 

*} 

{* 

AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF 

*} 

{* 

*} 

PROCEDURE  ADMMCRS  (MCRS: MCRS  REC); 


VAR 

FUNCTIONS:  BUFF5 ; 
DATASET  :  BUFF4; 
CODE  :  BUFF8 ; 
ELEMENTS:  BUFF80 ; 
BUFFER  :  BUFF80; 
ENDIT  :  BUFF  4 ; 
INDEX  :  INTEGER; 
OK  :  BOOLEAN; 


PROCEDURE  DATBAS ( ZSTDESCR  FUNCTIONS:  BUFF5 ;  STATUS:  BUFF4 ;  DATASET:  BUFF4; 

CODE:  BUFF8;  ELEMENTS:  BUFF80;  BUFFER: BUFF80;  ENDIT :BUFF4) ; 
FORTRAN; 

BEGIN 

FUNCTIONS  :=*  ' ADD-M' ; 

DATASET  :*  'MCRS'; 

CODE  :=  MCRS. CTRL; 

ELEMENTS  :=  MCRSCONSTI+MCRSCONST2 ; 

FOR  INDEX  :=»  1  TO  80  DO  BUFFER  [INDEX) 

ENDIT  'END.'; 

WITH  MCRS  DO  BEGIN 

BUFFER  :«  CTRL+CRHR+LCHR+LBHR+SZLM+TITL+REST+EXTRA+EXTRA; 

DATBAS ( FUNCTIONS , STATUS , DATASET , CODE , ELEMENTS , BUFFER , ENDIT) ; 
CHECKSTATUS(OK) 

END 


{*  DATE:  02/08/85  *} 
{*  NAME:  WRMMQTR  *} 
{*  DESCRIPTION:  THIS  MODULE  WRITES  AN  UPDATED  RECORD  BACK  TO  THE  *} 
{*  AFIT  DATABASE  IN  THE  MASTER  QUARTER  FILE.  THE  RECORD  *} 
{*  IS  PASSSED  TO  THE  MODULE  IN  THE  MQTR_REC  FORMAT.  *} 
{*  *} 
{*  FILES  READ:  NONE  *} 
{*  FILES  WRITTEN:  NONE  *} 
{*  GLOBAL  VARIABLES  USED:  NONE  *} 
{*  GLOBAL  VARIABLES  CHANGED:  NONE  *} 
{*  MODULES  CALLED:  CHECKSTATUS  *} 
{*  CALLING  MODULES:  *} 
{*  AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF  *} 
{*  *} 

PROCEDURE  WRTMSTRMQTR  ( MQTR : MQTR_REC ) ; 


VAR 


FUNCTIONS:  BUFF5 ; 

DATASET 

BUFF4; 

CODE 

BUFF4; 

ELEMENTS 

BUFF80; 

BUFFER 

BUFF80; 

ENDIT 

BUFF4; 

INDEX 

INTEGER 

OK 

BOOLEAN 

PROCEDURE  DATBAS ( ZSTDESCR  FUNCTIONS:  BUFF5 ;  STATUS:  BUFF4 ;  DATASET:  BUFF4; 

CODE:  BUFF4;  ELEMENTS:  BUFF80;  BUFFER :BUFF80;  ENDIT: BUFF4) ; 
FORTRAN; 

BEGIN 

FUNCTIONS  :*  'WRITM'; 

DATASET  :=■  'MQTR'; 

CODE  :=■  MQTR.  CTRL; 

ELEMENTS  :=>  MQTRCONSTI  +  EXTRA; 

FOR  INDEX  :=«  1  TO  80  DO  BUFFER  [INDEX]  :=  '  '; 

ENDIT  :»  'END.'; 

WITH  MQTR  DO  BEGIN 

BUFFER  :=  CTRL+STDT+SPDT+EXTRA+ EXTRA; 

DATBAS ( FUNCTIONS , STATUS , DATASET ,CODE , ELEMENTS , BUFFER , ENDIT) ; 
CHECKSTATUS (OK) 

END 


{* 

DATE:  02/08/85 

*} 

{* 

NAME:  RDMMQTR 

*} 

[* 

DESCRIPTION:  THIS  MODULE  READS  A 

MASTER  RECORD  FROM  THE  MASTER 

*} 

{* 

QUARTER  FILE  AND  FORMATS 

THE  RECORD  "MQTR"  OF  TYPE 

*} 

{* 

MQTR_REC  IF  THE  READ  WAS 

ACCOMPLISHED. 

*} 

{* 

*} 

{* 

FILES  READ:  AFITDB 

*} 

{* 

FILES  WRITTEN:  NONE 

*} 

{* 

GLOBAL  VARIABLES  USED:  NONE 

*} 

{* 

GLOBAL  VARIABLES  CHANGED:  NONE 

*} 

{* 

MODULES  CALLED:  CHECKSTATUS 

*} 

{* 

CALLING  MODULES: 

*} 

{* 

AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF 

*} 

{* 

*} 

PROCEDURE  RDMMQTR  (VAR  MQTR : MQTR_REC ;  C0DE:BUFF4); 

VAR 

FUNCTIONS:  BUFF5 ; 

DATASET  :  BUFF4; 

ELEMENTS:  BUFF80; 

BUFFER  :  BUFF80; 

END IT  :  BUFF4; 

INDEX  :  INTEGER; 

OK  :  BOOLEAN; 

PROCEDURE  DATBAS ( ZSTDESCR  FUNCTIONS:  BUFF5 ;  STATUS:  BUFF4;  DATASET:  BUFF4; 

CODE:  BUFF4;  ELEMENTS:  BUFF80;  BUFFER: BUFF80;  ENDIT: BUFF4) ; 
FORTRAN; 

BEGIN 

FUNCTIONS  :=  'READM'; 

DATASET  :=  'MQTR'; 

ELEMENTS  MQTRCONST1  +  EXTRA; 

FOR  INDEX  :=■  1  TO  80  DO  BUFFER  [iNDEXl 
ENDIT  :=*  'END.'; 

WITH  MQTR  DO  BEGIN 

DATBAS ( FUNCTIONS , STATUS , DATASET , CODE , ELEMENTS , BUFFER , ENDIT ) ; 
CHECKSTATUS(OK) ; 

IF  OK  THEN  BEGIN 

FOR  INDEX  :*  1  TO  4  DO  BEGIN 

CTRL  [INDEX]  :=  BUFFER  [INDEX]; 

STDT  [INDEX]  :»  BUFFER  [INDEX  +4]; 

SPOT  [INDEX]  :=  BUFFER  [INDEX  +  10] 

END; 

FOR  INDEX  :*  5  TO  6  DO  BEGIN 

STDT  [INDEX]  :»  BUFFER  [INDEX  +  4]; 

SPDT  [INDEX]  :-  BUFFER  [INDEX  +  10] 

END 

END 
END  END; 
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{  kit  it* 

*************  »******************»*<ri>r**<rtlr<r**<nl 

r*********** ********* 

***} 

{* 

DATE:  02/08/85 

*} 

{* 

NAME:  ADMMQTR 

*) 

{* 

DESCRIPTION:  THIS  MODULE  ADDS  A  RECORD  TO 

THE  MASTER  QUARTER 

*} 

(* 

FILE  IN  THE  AFIT  DATABASE.  THE  RECORD  MUST  NO  EXIT 

*} 

{* 

AND  MUST  BE  PASSED  TO  THIS  MODULE 

IN  THE  MQTR  REC 

*} 

{* 

FORMAT. 

*} 

{* 

*} 

{* 

FILES  READ:  NONE 

*} 

{* 

FILES  WRITTEN:  AFITDB 

*} 

{* 

GLOBAL  VARIABLES  USED:  NONE 

*] 

{* 

GLOBAL  VARIABLES  CHANGED:  NONE 

*) 

{* 

MODULES  CALLED:  CHECKSTATUS 

*} 

{* 

CALLING  MODULES: 

*} 

{* 

AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF 

*} 

{* 

1  ■*+++ 

*} 

■+++  \ 

PROCEDURE  ADMMQTR  ( MQTR : MQTR_REC ) ; 
VAR 


FUNCTIONS:  BUFF5; 

DATASET 

BUFF4; 

CODE 

BUFF4 ; 

ELEMENTS 

BUFF80 ; 

BUFFER 

BUFF80 ; 

ENDIT 

BUFF4 ; 

INDEX 

INTEGER 

OK 

BOOLEAN 

PROCEDURE  DATBAS( ZSTDESCR  FUNCTIONS:  BUFF5 ;  STATUS:  BUFF4;  DATASET:  BUFF4; 

CODE:  BUFF4;  ELEMENTS:  BUFF80;  BUFFER: BUFF80;  ENDIT: BUFF4) ; 
FORTRAN; 

BEGIN 

FUNCTIONS  :=  'ADD-M'; 

DATASET  :*  'MQTR'; 

CODE  :»  MQTR. CTRL; 

ELEMENTS  :-  MQTRCONST1  +  EXTRA; 

FOR  INDEX  :»  1  TO  80  DO  BUFFER  [INDEX]  :=■  '  '; 

ENDIT  :*  'END.'; 

WITH  MQTR  DO  BEGIN 

BUFFER  :*  CTRL+STDT+SPDT+EXTRA+EXTRA; 

DATBAS ( FUNCTIONS , STATUS , DATASET , CODE , ELEMENTS , BUFFER, ENDIT) ; 
CHECKSTATUS(OK) 

END 

END; 


ss 


{*  DATE:  08/08/85  *} 
{*  NAME:  ADVCRSE  *} 
{*  DESCRIPTION:  THIS  MODULE  ADDS  A  VARIABE  RECORD  TO  THE  CRSE  *} 
{*  VARIABLE  FILE  AFTER  THE  RECORD  POINTED  TO  BY  THE  *} 
{*  VREFERENCE  PARAMETER.  THE  INFORMATION  PASSED  TO  THIS  *} 
{*  MODULE  IS  IN  THE  RECORD  FORMAT  OF  TYPE  CRSE_REC.  *} 
{*  *} 
{*  FILES  READ:  NONE  *} 
{*  FILES  WRITTEN:  AFITDB  *} 
{*  GLOBAL  VARIABLES  USED:  NONE  *} 
{*  GLOBAL  VARIABLES  CHANGED:  NONE  *} 
{*  MODULES  CALLED:  CHECKSTATUS  *} 
{*  CALLING  MODULES:  LAYER  4,  AND  LAYER  3  *} 
{*  AUTHOR:  DAVID  A  GAITROS,  CAPT,  USAF  *} 
{*  *} 


PROCEDURE  ADVCRSE(CRSE:CRSE_REC; VAR  VREFERENCE :BUFF4; 

CODE  : BUFF9 ) ; 

VAR 

FUNCTIONS:  BUFF5 ; 

DATASET  :  BUFF4; 

VLINKPATH:  BUFF8; 

ELEMENTS  :  BUFF80; 

BUFFER  :  BUFF240; 

ENDIT  :  BUFF4; 

INDEX  :  INTEGER; 

OK  :  BOOLEAN; 

PROCEDURE  DATBAS  (ZSTDESCR  FUNCTIONS : BUFF5 ;  STATUS :BUFF4;  DATASET : BUFF4 ; 

VREFERENCE :BUFF4;  VLINKPATH :BUFF8;  CODE:  BUFF9 ; 

ELEMENTS:  BUFF80;  BUFFER:  BUFF240 ;  ENDIT:  BUFF4) ;  FORTRAN; 


BEGIN 

FUNCTIONS  :=  'ADDVC'; 

ENDIT  :*  'END.'; 

DATASET  :*  'CRSE'; 

VLINKPATH  :-  ' STDTLKCR' ; 

ELEMENTS  :»  CRSEC0NST1+CRSEC0NST2 ; 

FOR  INDEX  :-  I  TO  240  DO 
BUFFER  [INDEX]  :»  '  '; 

WITH  CRSE  DO  BEGIN 

BUFFER  :*STDT+MDEG+NUMB+NAME+GRAD+BEGN+COLL+WAIV+EXTRA+EXTRA+EXTRA+ 
EXTRA+EXTRA; 

DATBAS  ( FUNCTIONS , STATUS , DATASET , VREFERENCE , VLINKPATH , CODE , ELEMENTS , 
BUFFER, ENDIT); 

CHECKSTATUS (OK) 

END 

END;  (*  ADVCRSE  *} 


{  1rk-M1rk1fkirk*1rk1t1ck1fk1fkie1rk1rk1tit*it1t*1fk*1t1t1eifk*1i*1rk*-k1rkifkis1ckitirk-kit1t1rk1c1eitirk*1rkic1ckic  } 


{*  DATE:  08/08/85  *} 

{*  NAME:  WRVCRSE  *} 

{*  DESCRIPTION:  THIS  MODULE  WRITES  AN  UPDATED  VARIABLE  RECORD  *} 

{*  FROM  THE  FILE  CRSE  TO  THE  DATABASE  TO  ITS  ORIGINAL  *} 

{*  POSITION  WITHIN  THE  STRING.  THE  INFORMATION  IS  PASSED  *} 

{*  TO  THE  MODULE  VIA  THE  RECORD  IN  THE  CRSE  REC  FORMAT.  *} 

{*  *} 

{*  FILES  READ:  NONE  *} 

{*  FILES  WRITTEN:  AFITDB  *} 

{*  GLOBAL  VARIABLES  USED:  NONE  *} 

{*  GLOBAL  VARIABLES  CHANGED:  NONE  *} 

{*  MODULES  CALLED:  CHECKSTATUS  *} 

{*  CALLING  MODULES:  LAYER  4,  AND  LAYER  3  *} 

{*  AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF  *} 

{*  *} 

PROCEDURE  WRVCRSE( CRSE :CRSE_REC; VAR  VREFERENCE : BUFF4 ; 

VLINKPATH  : BUFF8 ; 

CODE  : BUFF9) : 


VAR 

FUNCTIONS:  BUFF5 ; 

DATASET  :  BUFF4 ; 

ELEMENTS  :  BUFF80; 

BUFFER  :  BUFF240 ; 

ENDIT  :  8UFF4; 

INDEX  :  INTEGER; 

OK  :  BOOLEAN; 

PROCEDURE  DATBAS  (%STDESCR  FUNCTIONS : BUFF5 ;  STATUS : BUFF4;  DATASET : BUFF4 ; 

VREFERENCE :BUFF4;  VLINKPATH: BUFF8 ;  CODE:  BUFF9 ; 

ELEMENTS:  BUFF80;  BUFFER:  BUFF240 ;  ENDIT:  BUFF4) ;  FORTRAN; 


BEGIN 

FUNCTIONS  :=  'WRITV'; 

ENDIT  'END.'; 

DATASET  :*  'CRSE'; 

ELEMENTS  :-  CRSECONST1+CRSECONST2 ; 

FOR  INDEX  :*  1  TO  240  DO 
BUFFER  [INDEX]  :*  '  '; 

WITH  CRSE  DO  BEGIN 

BUFFER  :®STDT+MDEG+NUMB+NAME+GRAD+BEGN+COLL+WAIV+EXTRA+EXTRA+EXTRA+ 
EXTRA+EXTRA; 

DATBAS  ( FUNCT IONS , STATUS , DATAS ET , VREFERENCE , VL INKPATH , CODE , ELEMENTS , 
BUFFER, ENDIT); 

CHECKSTATUS (OK) 

END 

END;  {*  WRVCRSE  *} 


{*  DATE:  08/08/85  *} 

{*  NAME:  RDVCRSE  *} 

{*  DESCRIPTION:  THIS  MODULE  READS  A  VARIBLE  FILE  FROM  THE  DATABASE  *} 

{*  FROM  THE  FILE  CRSE.  IT  FORMATS  THE  INFORMATION  INTO  *} 

{*  A  RECORD  OF  TYPE  CRSE_REC  AND  RETURNS  IT  TO  THE  *} 

{*  CALLING  PROCEDURE.  *} 

{*  *} 

{*  FILES  READ:  AFITDB  *} 

{*  FILES  WRITTEN:  NONE  *} 

{*  GLOBAL  VARIABLES  USED:  NONE  *} 

{*  GLOBAL  VARIABLES  CHANGED:  NONE  *} 

{*  MODULES  CALLED:  CHECKSTATUS  *} 

{*  CALLING  MODULES:  LAYER  4,  AND  LAYER  3  *} 

{*  AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF  *} 

{*  *} 

PROCEDURE  RDVCRSE( VAR  CRSE:CRSE_REC;  VAR  VREFERENCE : BUFF4 ; 

CODE  : BUFF9 ) ; 


VAR 

FUNCTIONS:  BUFF5; 

DATASET  :  BUFF4 ; 

ELEMENTS  :  BUFF80; 

VLINKPATH:  BUFF8 ; 

BUFFER  :  BUFF240; 

ENDIT  :  BUFF4; 

INDEX  :  INTEGER; 

OK  :  BOOLEAN; 

PROCEDURE  DATBAS  (XSTDESCR  FUNCTIONS : BUFF5 ;  STATUS : BUFF4 ;  DATASET : BUFF4 ; 

VREFERENCE :BUFF4;  VLINKPATH :BUFF8;  CODE:  BUFF9 ; 

ELEMENTS:  BUFF80;  BUFFER:  BUFF240;  ENDIT:  BUFF4) ;  FORTRAN 


BEGIN 

FUNCTIONS  :*  'READV'; 

ENDIT  :»  'END.'; 

DATASET  :*  'CRSE'; 

VLINKPATH  :=*  'STDTLKCR' ; 

ELEMENTS  :*  CRSECONST1+CRSECONST2 ; 

FOR  INDEX  :«  1  TO  240  DO 
BUFFER  [INDEX]  :*  '  '; 

WITH  CRSE  DO  BEGIN 

DATBAS  ( FUNCT IONS , STATUS , DAT AS ET , VREFERENCE , VL INKPATH , CODE , 
ELEMENTS , BUFFER , ENDIT) ; 

CHECKSTATUS (OK); 

IF  OK  THEN  BEGIN 

WAIV  :»  BUFFER  [75] ; 

FOR  INDEX  1  TO  9  DO  STDT  [INDEX]  BUFFER  [INDEX]; 

FOR  INDEX  :*  1  TO  2  DO  MDEG  [INDEX]  :=*  BUFFER  [INDEX  +9]; 

FOR  INDEX  :*  1  TO  8  DO  NUMB  [INDEX]  :=  BUFFER  [INDEX  +  11]; 

FOR  INDEX  :*  1  TO  20  DO  NAME  [INDEX]  :«  BUFFER  [INDEX  +  19] ; 


FOR  INDEX  :*  1  TO  2  DO  GRAD  [INDEX]  BUFFER  [INDEX  +  39] ; 
FOR  INDEX  :=  1  TO  4  DO  BEGN  [INDEX]  :=  BUFFER  [INDEX  +41]; 
FOR  INDEX  :=  1  TO  30  DO  COLL  [INDEX]  :=  BUFFER  [INDEX  +  45] 

END 

END 

RDVCRSE  *} 


{*  DATE:  08/08/85  *} 

{*  NAME:  RDDCRSE  *} 

{*  DESCRIPTION:  THIS  MODULE  READS  A  VARIABLE  FILE  RECORD  FROM  THE  *} 

{*  FILE  CRSE  DIRECTLY  FROM  THE  DATABASE  USING  THE  POINTER  *} 

{*  PARAMETER  PREFERENCE"  AS  THE  KEY.  THE  INFORMATION  IS  *} 

{*  FORMATTED  AND  STORED  IN  A  RECORD  OF  TYPE  CRSE  REC;  *} 

{*  *} 

{*  FILES  READ:  AFITDB  *} 

{*  FILES  WRITTEN:  NONE  *} 

{*  GLOBAL  VARIABLES  USED:  NONE  *} 

{*  GLOBAL  VARIABLES  CHANGED:  NONE  *} 

{*  MODULES  CALLED:  CHECKSTATUS  *} 

{*  CALLING  MODULES:  LAYER  4,  AND  LAYER  3  *} 

{*  AUTHOR:  DAVID  A  GAITROS ,  CAPf,  USAF  *} 

{*  *} 

PROCEDURE  RDDCRSE(VAR  CRSE : CRSE_REC;  VAR  VREFERENCE : BUFF4 ; 

VLINKPATH  : BUFF8 ; 

CODE  : BUFF9) ; 


VAR 

FUNCTIONS:  BUFF5 ; 

DATASET  :  BUFF4; 

ELEMENTS  :  BUFF80; 

BUFFER  :  BUFF240 ; 

ENDIT  :  BUFF4; 

INDEX  :  INTEGER; 

OK  :  BOOLEAN; 

PROCEDURE  DATBAS  (%STDESCR  FUNCTIONS : BUFF5 ;  STATUS :BUFF4;  DATASET :BUFF4; 

VREFERENCE :BUFF4;  VLINKPATH: BUFFS;  CODE:  BUFF9 ; 

ELEMENTS:  BUFF80;  BUFFER:  BUFF240;  ENDIT:  BUFF4) ;  FORTRAN 


BEGIN 

FUNCTIONS  :=  'READD'; 

ENDIT  :=*  'END.'; 

DATASET  :=  'CRSE'; 

ELEMENTS  :=  CRSECONST1+CRSECONST2 ; 

FOR  INDEX  :=*  1  TO  240  DO 
BUFFER  [INDEX]  :=  '  '; 

WITH  CRSE  DO  BEGIN 

DATBAS  ( FUNCTIONS , STATUS , DATASET , VREFERENCE , VLINKPATH , CODE , 
ELEMENTS , BUFFER , ENDIT) ; 

CHECKSTATUS (OK); 

IF  OK  THEN  BEGIN 

WAIV  :-  BUFFER  [75]; 

FOR  INDEX  :-  1  TO  9  DO  STDT  [INDEX]  :=  BUFFER  [INDEX]; 

FOR  INDEX  :=  1  TO  2  DO  MDEG  [INDEX]  :=  BUFFER  [INDEX  +9]; 

FOR  INDEX  :-  I  TO  8  DO  NUMB  [INDEX]  :=  BUFFER  [INDEX  +  11]; 

FOR  INDEX  :«  1  TO  20  DO  NAME  [INDEX]  :=  BUFFER  [INDEX  +  19]; 

FOR  INDEX  :*  1  TO  2  DO  GRAD  [INDEX]  :=  BUFFER  [INDEX  +  39]; 


vy. 


FOR  INDEX  :=  1  TO  4  DO  BEGN  [INDEX]  :=  BUFFER  [INDEX  +41]; 
FOR  INDEX  :=  1  TO  30  DO  COLL  [INDEX]  :=  BUFFER  [INDEX  +  45] 

END 

END 

END;  {*  RDDCRSE  *} 
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{*  DATE:  08/08/85  *} 

(*  NAME:  DLDCRSE  *} 

{*  DESCRIPTION:  THIS  MODULE  DELETES  A  RECORD  FROM  THE  DATABASE  *} 

{*  FROM  THE  FILE  CRSE.  THIS  RECORD  MUST  HAVE  BEEN  READ  *} 

{*  FIRST  WITH  INTENT  TO  UPDATE  AND  THE  RECORD  POINTER  *} 

{*  PASSED  TO  THIS  MODULE  IN  THE  PARAMETER  "VREFERENCE" .  *} 

{*  *} 

{*  FILES  READ:  NONE  *} 

(*  FILES  WRITTEN:  AFITDB  *} 

{*  GLOBAL  VARIABLES  USED:  NONE  *} 

{*  GLOBAL  VARIABLES  CHANGED:  NONE  *} 

{*  MODULES  CALLED:  CHECKSTATUS  *} 

{*  CALLING  MODULES:  LAYER  4,  AND  LAYER  3  *} 

{*  AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF  *} 

{*  *} 

PROCEDURE  DLDCRSE( VAR  CRSE:CRSE_REC;  VAR  VREFERENCE : BUFF4 ; 

CODE  : BUFF9 ) ; 

VAR 

FUNCTIONS:  BUFF5 ; 

DATASET  :  BUFF4; 

VLINKPATH:  BUFF8; 

ELEMENTS  :  BUFF80; 

BUFFER  :  BUFF240; 

ENDIT  :  BUFF4; 

INDEX  :  INTEGER; 

OK  :  BOOLEAN; 

PROCEDURE  DATBAS  (%STDESCR  FUNCTIONS : BUFF5 ;  STATUS : BUFF4 ;  DATASET : BUFF4 ; 

VREFERENCE: BUFF4;  VLINKPATH : BUFF8 ;  CODE:  BUFF9 ; 

ELEMENTS:  BUFF80;  BUFFER:  BUFF240;  ENDIT:  BUFF4) ;  FORTRAN 

BEGIN 

FUNCTIONS  :=»  '  READV'  ; 

ENDIT  :=  'END.'; 

VLINKPATH  :=*  'STDTLKCR' ; 

DATASET  :=  'CRSE'; 

ELEMENTS  :=  CRSECONST1+CRSECONST2 ; 

FOR  INDEX  :=  1  TO  240  DO 
BUFFER  [INDEX] 

DATBAS  ( FUNCTIONS , STATUS , DATASET , VREFERENCE , VLINKPATH , CODE , 
ELEMENTS , BUFFER , ENDIT) ; 

CHECKSTATUS (OK) ; 

IF  (OK)  AND  (VREFERENCE  <>  'END.') THEN  BEGIN 
FUNCTIONS  :«  'READV'; 

DATBAS  ( FUNCTIONS , STATUS , DATAS ET , VREFERENCE , VL INKPATH , CODE , 
ELEMENTS , BUFFER , ENDIT) ; 

CHECKSTATUS (OK); 

END; 

END;  {*  DLDCRSE  *} 
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{★★♦★A*******************************************************************} 


{*  DATE:  08/08/85  *} 
{*  NAME:  ADCVREQ  *} 
{*  DESCRIPTION:  THIS  MODULE  ADDS  A  VARIABE  RECORD  TO  THE  VREQ  *} 
{*  VARIABLE  FILE  AFTER  THE  RECORD  POINTED  TO  BY  THE  *} 
{*  VREFERENCE  PARAMETER.  THE  INFORMATION  PASSED  TO  THIS  *} 
{*  MODULE  IS  IN  THE  RECORD  FORMAT  OF  TYPE  VREQ  REC.  *} 
{*  *} 
{*  FILES  READ:  NONE  *} 
{*  FILES  WRITTEN:  AFITDB  *} 
{*  GLOBAL  VARIABLES  USED:  NONE  *} 
{*  GLOBAL  VARIABLES  CHANGED:  NONE  *} 
{*  MODULES  CALLED:  CHECKSTATUS  *} 
{*  CALLING  MODULES:  LAYER  4,  AND  LAYER  3  *} 
{*  AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF  *} 
{*  *} 


{ ************************************************************************ } 


PROCEDURE  ADCVREQ( VREQ :VREQ_REC; VAR  VREFERENCE :BUFF4; 

VLINKPATH  :BUFF8; 

CODE  : BUFF8) ; 

VAR 

FUNCTIONS:  BUFF5 ; 

DATASET  :  BUFF4; 

ELEMENTS  :  BUFF80 ; 

BUFFER  :  BUFF240 ; 

ENDIT  :  BUFF4 ; 

INDEX  :  INTEGER; 

OK  :  BOOLEAN; 

PROCEDURE  DATBAS  USTDESCR  FUNCTIONS : BUFF5 ;  STATUS : BUFF4 ;  DATASET : BUFF4 ; 

VREFERENCE: BUFF4;  VLINKPATH : BUFF8 ;  CODE:  BUFF8 ; 

ELEMENTS:  BUFF80;  BUFFER:  BUFF240;  ENDIT:  BUFF4) ;  FORTRAN; 


BEGIN 

FUNCTIONS  :=  ' ADDVC' ; 

ENDIT  :=*  'END.'; 

DATASET  :=*  'VREQ'; 

ELEMENTS  :=  VREQCONST1+VREQCONST2 ; 

FOR  INDEX  :»  I  TO  240  DO 
BUFFER  [INDEX]  :=  '  '; 

WITH  VREQ  DO  BEGIN 

BUFFER  :*CODE+NMBR+DATA+RNUM+BLKA+PNUM+BLKB+EXTRA+EXTRA+EXTRA+ EXTRA 
+ EXTRA; 

END; 

DATBAS  ( FUNCTIONS , STATUS , DATASET , VREFERENCE , VLINKPATH , CODE , ELEMENTS , 
BUFFER, ENDIT); 

CHECKSTATUS (OK) 

END;  {*  ADVVREQ  *} 


i 

J 


{*  DATE:  08/08/85  *} 

{*  NAME:  WRVVREQ  *} 

{*  DESCRIPTION:  THIS  MODULE  WRITES  AN  UPDATED  VARIABLE  RECORD  *} 

{*  FROM  THE  FILE  VREQ  TO  THE  DATABASE  TO  ITS  ORIGINAL  *} 

{*  POSITION  WITHIN  THE  STRING.  THE  INFORMATION  IS  PASSED  *} 

{*  TO  THE  MODULE  VIA  THE  RECORD  IN  THE  VREQ_REC  FORMAT.  *} 

{*  *} 

{*  FILES  READ:  NONE  *} 

{*  FILES  WRITTEN:  AFITDB  *} 

{*  GLOBAL  VARIABLES  USED:  NONE  *} 

{*  GLOBAL  VARIABLES  CHANGED:  NONE  *} 

{*  MODULES  CALLED:  CHECKSTATUS  *} 

{*  CALLING  MODULES:  LAYER  4,  AND  LAYER  3  *} 

{*  AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF  *} 

{*  *} 

PROCEDURE  WRVVREQ( VREQ :VREQ_REC; VAR  VREFERENCE: BUFF4; 

VLINKPATH  : BUFF8 ; 

CODE  : BUFF8) ; 


VAR 

FUNCTIONS:  BUFF5 ; 

DATASET  :  BUFF4; 

ELEMENTS  :  BUFF80; 

BUFFER  :  BUFF240; 

ENDIT  :  BUFF4; 

INDEX  :  INTEGER; 

OK  :  BOOLEAN; 

PROCEDURE  DATBAS  USTDESCR  FUNCTIONS :BUFF5;  STATUS :BUFF4;  DATASET: BUFF4 ; 

VREFERENCE :BUFF4;  VLINKPATH :BUFF8;  CODE:  BUFF8 ; 

ELEMENTS:  BUFF80;  BUFFER:  BUFF240;  ENDIT:  BUFF4) ;  FORTRAN; 


BEGIN 

FUNCTIONS  :=  'WRITV'; 

ENDIT  :=  'END.'; 

DATASET  :=  'VREQ'; 

ELEMENTS  :=  VREQCONST1+VREQCONST2 ; 

FOR  INDEX  :=  1  TO  240  DO 
BUFFER  [INDEX]  :=  '  '; 

WITH  VREQ  DO  BEGIN 

BUFFER  : -CODE+NMBR+DATA+RNUM+BLKA+PNUM+BLKB+EXTRA+EXTRA+EXTRA+ 

EXTRA  +  EXTRA 

END; 

DATBAS  ( FUNCTIONS , STATUS , DATASET , VREFERENCE , VLINKPATH , CODE , ELEMENTS , 
BUFFER, END IT); 

CHECKSTATUS (OK) 

END;  {*  WRVVREQ  *} 


{  1c**************************-)'********************************************  } 


{*  DATE:  08/08/85  *} 

{*  NAME:  RDVVREQ  *} 

{*  DESCRIPTION:  THIS  MODULE  READS  A  VARIBLE  FILE  FROM  THE  DATABASE  *} 

{*  FROM  THE  FILE  VREQ.  IT  FORMATS  THE  INFORMATION  INTO  *} 

{*  A  RECORD  OF  TYPE  VREQ_REC  AND  RETURNS  IT  TO  THE  *} 

{*  CALLING  PROCEDURE.  *} 

{*  *} 

{*  FILES  READ:  AFITDB  *} 

{*  FILES  WRITTEN:  NONE  *} 

{*  GLOBAL  VARIABLES  USED:  NONE  *} 

{*  GLOBAL  VARIABLES  CHANGED:  NONE  *} 

{*  MODULES  CALLED:  CHECKSTATUS  *} 

{*  CALLING  MODULES:  LAYER  4,  AND  LAYER  3  *} 

{*  AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF  *} 

I*  *} 

PROCEDURE  RDVVREQ(VAR  VREQ:VREQ_REC;  VAR  VREFERENCE : BUFF4 ; 

VLINKPATH  : BUFF8 ; 

CODE  : BUFF8) ; 


VAR 

FUNCTIONS:  BUFF5; 

DATASET  :  BUFF4 ; 

ELEMENTS  :  BUFF80; 

BUFFER  :  BUFF240; 

ENDIT  :  BUFF4; 

INDEX  :  INTEGER; 

OK  :  BOOLEAN; 

PROCEDURE  DATBAS  (%STDESCR  FUNCTIONS : BUFF5 ;  STATUS :BUFF4;  DATASET :BUFF4; 

VREFERENCE :BUFF4;  VLINKPATH : BUFF8 ;  CODE:  BUFF8 ; 

ELEMENTS:  BUFF80;  BUFFER:  BUFF240;  ENDIT:  BUFF4) ;  FORTRAN 


BEGIN 

FUNCTIONS  :»  ' READV' ; 

ENDIT  :=  'END.'; 

DATASET  :«  'VREQ'; 

ELEMENTS  :=  VREQCONST1+VREQCONST2 ; 

FOR  INDEX  :*  1  TO  240  DO 
BUFFER  [INDEX]  :«  '  '; 

DATBAS  ( FUNCTIONS , STATUS , DATASET , VREFERENCE , VLINKPATH , CODE, 
ELEMENTS , BUFFER, ENDIT) ; 

CHECKSTATUS (OK); 

WITH  VREQ  DO  BEGIN 
IF  OK  THEN  BEGIN 

FOR  INDEX  :-  1  TO  2  DO  CODE  [INDEX]  :«  BUFFER  [INDEX]; 

FOR  INDEX  :*  1  TO  8  DO  NMBR  [INDEX]  :=  BUFFER  [INDEX+2]; 

FOR  INDEX  :*  1  TO  6  DO  BEGIN 

RNUM  [INDEX]  :-  BUFFER  [INDEX  +  22]; 

BLKA  [INDEX]  :-  BUFFER  [INDEX  +28]; 

PNUM  [INDEX]  :-  BUFFER  [INDEX  +  34] ; 


BLKB  [INDEX]  BUFFER  [INDEX  +  40] 

END; 

FOR  INDEX  :=■  1  TO  12  DO  DATA  [INDEX]  BUFFER  [INDEX+10] 

END 

END 

END;  {*  RDVVREQ  *} 


{*  DATE:  08/08/85  *} 

{*  NAME:  RDDVREQ  *} 

{*  DESCRIPTION:  THIS  MODULE  READS  A  VARIABLE  FILE  RECORD  FROM  THE  *} 

{*  FILE  VREQ  DIRECTLY  FROM  THE  DATABASE  USING  THE  POINTER  *} 

{*  PARAMETER  "VREFERENCE”  AS  THE  KEY.  THE  INFORMATION  IS  *} 

{*  FORMATTED  AND  STORED  IN  A  RECORD  OF  TYPE  VREQ  REC;  *} 

{*  “  *} 
{*  FILES  READ:  AFITDB  *} 

{*  FILES  WRITTEN:  NONE  *} 

{*  GLOBAL  VARIABLES  USED:  NONE  *} 

{*  GLOBAL  VARIABLES  CHANGED:  NONE  *} 

{*  MODULES  CALLED:  CHECKSTATUS  *} 

{*  CALLING  MODULES:  LAYER  4,  AND  LAYER  3  *} 

{*  AUTHOR:  DAVID  A  GAITROS,  CAPT,  USAF  *} 

{*  *} 

PROCEDURE  RDDVREQ (VAR  VREQ : VREQ_REC;  VAR  VREFERENCE : BUFF4 ; 

VLINKPATH  : BUFF8 ; 

CODE  : BUFF8 ) ; 


VAR 

FUNCTIONS:  BUFF5 ; 

DATASET  :  BUFF4 ; 

ELEMENTS  :  BUFF80; 

BUFFER  :  BUFF240 ; 

ENDIT  :  BUFF4; 

INDEX  :  INTEGER; 

OK  :  BOOLEAN; 

PROCEDURE  DATBAS  (ZSTDESCR  FUNCTIONS :BUFF5 ;  STATUS: BUFF4;  DATASET: BUFF4; 

VREFERENCE: BUFF4;  VLINKPATH :BUFF8;  CODE:  BUFF8 ; 

ELEMENTS:  BUFF80;  BUFFER:  BUFF240;  ENDIT:  BUFF4) ;  FORTRAN 


BEGIN 

FUNCTIONS  :=■  'READD'; 

ENDIT  :»  'END.'; 

DATASET  :«  'VREQ'; 

ELEMENTS  :=  VREQCONST1+VREQCONST2 ; 

FOR  INDEX  :=»  1  TO  240  DO 
BUFFER  [INDEX]  :»  '  '; 

DATBAS  ( FUNCTIONS , STATUS , DATASET , VREFERENCE , VLINKPATH , CODE, 
ELEMENTS , BUFFER , ENDIT) ; 

CHECKSTATUS (OK) ; 

WITH  VREQ  DO  BEGIN 
IF  OK  THEN  BEGIN 

FOR  INDEX  :*  1  TO  2  DO  CODE  [INDEX]  :«  BUFFER  [INDEX]; 
FOR  INDEX  :=  I  TO  6  DO  BEGIN 

RNUM  [INDEX]  :-  BUFFER  [INDEX  +  22]; 

BLKA  [INDEX]  :=  BUFFER  [INDEX  +  28); 

PNUM  [INDEX]  :«  BUFFER  [INDEX  +  34] 

END; 


FOR  INDEX  :»  1  TO  8  DO  NMBR  [INDEX]  BUFFER  [INDEX  +2]; 
FOR  INDEX  :«  1  TO  12  DO  DATA  [INDEX]  BUFFER  [INDEX  +10] 

END 

END 

END;  {*  RDDVREQ  *} 


w 
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{* 

DATE:  08/08/85 

*} 

’  (■ 

{* 

NAME:  DLDVREQ 

*} 

i* 

DESCRIPTION:  THIS  MODULE  DELETES  A  RECORD  FROM  THE 

DATABASE 

*} 

H 

{* 

FROM  THE  FILE  VREQ.  THIS  RECORD  MUST  HAVE 

BEEN  READ 

*} 

i* 

FIRST  WITH  INTENT  TO  UPDATE  AND  THE  RECORD 

POINTER 

*} 

V  -V 

{* 

PASSED  TO  THIS  MODULE  IN  THE  PARAMETER  "VREFERENCE”. 

*} 

{* 

*} 

•VMl 
,  ^ 

{* 

FILES  READ:  NONE 

*} 

y 

(* 

FILES  WRITTEN:  AFITDB 

*} 

AS 

{* 

GLOBAL  VARIABLES  USED:  NONE 

*} 

{* 

GLOBAL  VARIABLES  CHANGED:  NONE 

*} 

{* 

MODULES  CALLED:  CHECKSTATUS 

*} 

m 

{* 

CALLING  MODULES:  LAYER  4,  AND  LAYER  3 

*} 

{* 

AUTHOR:  DAVID  A  GAITROS,  CAPT,  USAF 

*} 

MJI.1 

{* 

*} 

PROCEDURE  DLDVREQ( VAR  VREQ : VREQ_REC;  VAR  VREFERENCE: BUFF4 

VLINKPATH  : BUFF8 
CODE  : BUFF8 ) 


IV. v 


r.  j 


VAR 


FUNCTIONS 

BUFF5 ; 

DATASET 

BUFF4; 

ELEMENTS 

BUFF80; 

BUFFER 

BUFF240; 

ENDIT 

BUFF4; 

INDEX 

INTEGER; 

OK 

BOOLEAN; 

PROCEDURE  DATBAS  (XSTDESCR  FUNCTIONS :BUFF5;  STATUS : BUFF4 ;  DATASET : BUFF4 ; 

VREFERENCE: BUFF4;  VLINKPATH :BUFF8;  CODE:  BUFF8 ; 

ELEMENTS:  BUFF80;  BUFFER:  BUFF240;  ENDIT:  BUFF4) ;  FORTRAN; 


BEGIN 


END; 


FUNCTIONS  :»  'DELVD'; 

ENDIT  :»  'END.'; 

DATASET  :=  'VREQ'; 

ELEMENTS  :=  VREQCONST1+VREQCONST2 ; 

FOR  INDEX  :=  1  TO  240  DO 
BUFFER  [INDEX] 

DATBAS  ( FUNCTIONS , STATUS , DATASET, VREFERENCE, VLINKPATH , CODE , 
ELEMENTS , BUFFER , ENDIT) ; 

CHECKSTATUS(OK) ; 

{*  DLDVREQ  *} 


r- 


'•to 


O 


{ ******************************* ********* ******************************** } 


{* 

DATE; 19/07/85 

*1 

{* 

NAME:  CONVERT  TO 

DISP 

*} 

{* 

DESCRIPTION: 

CONVERTS  A  NUMERIC  INTEGER  INTO  A  3  DIGIT 

*} 

{* 

DISPLAY  CHARACTERS. 

*} 

{* 

*} 

{* 

FILES  READ: 

*} 

{* 

FILES  WRITTEN: 

*} 

{* 

GLOBAL  VARIABLES  USED: 

*} 

{* 

GLOBAL  VARIABLES  CHANGED: 

*} 

{* 

MODULES  CALLED: 

*} 

{* 

CALLING  MODULES: 

*} 

{* 

AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF 

*} 

l* 

*} 

{******1 

k* ************ 

nHribWti 

Hr*  ************************  ***************** 

Hr***} 

FUNCTION  CONVERT  TO  DISP( INNUM: INTEGER) :  BUFF3 ; 

VAR 

HOLDDISP:  BUFF3 ; 

DIVISOR  :  INTEGER; 

HOLDNUMB:  INTEGER; 

INDEX  :  INTEGER; 

DISPNUM  :  PACKED  ARRAY  [0..9]  OF  CHAR; 

BEGIN 

DISPNUM  [01 

-  'O' 

DISPNUM  [1] 

=*  'i' 

DISPNUM  [2] 

-  '2' 

DISPNUM  [31 

*  '3' 

DISPNUM  [4] 

=*  '4' 

DISPNUM  [5] 

*  '  5' 

DISPNUM  [61 

-  '6' 

DISPNUM  [7] 

*  '7' 

DISPNUM  [81 

*  'S' 

DISPNUM  [91 

=»  '9' 

HOLDNUMB  :=■  INNUM; 

DIVISOR  :=«  INNUM; 

FOR  INDEX  := 

3  DOWNTO  1  DO  BEGIN 

DIVISOR 

»  DIVISOR  DIV  10; 

DIVISOR 

»  DIVISOR*10;  [*  STRIP  OFF  LAST  DIGIT  *} 

HOLDDISP 

[INDEX1  :=  DISPNUM  [HOLDNUMB  -  DIVISOR]; 

HOLDNUMB 

:*  HOLDNUMB  DIV  10; 

DIVISOR 

*  DIVISOR  DIV  10 

END; 

CONVERT  TO  DISP  :=■ 

HOLDDISP; 

END; 
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{*  DATE:  *} 
{*  NAME:  READS ECT  *} 
[*  DESCRIPTION:  READS  THE  SECTION  THAT  A  STUDENT  BELONGS  TO.  *} 
{*  *} 
{*  FILES  READ:  *} 
{*  FILES  WRITTEN:  *} 
{*  GLOBAL  VARIABLES  USED:  *} 
{*  GLOBAL  VARIABLES  CHANGED:  *} 
{*  MODULES  CALLED:  *} 
{*  CALLING  MODULES:  *} 
{*  AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF  *} 
{* 

{* 


PROCEDURE  RDVSECL( VAR  SECL : SECL_REC ; VAR  VREFERENCE: BUFF4;  SSAN:BUFF9) 
VAR  TEMPBUFF20  :  BUFF20; 

OK  :  BOOLEAN; 

VLINKPATH  :  BUFF8; 

FUNCTIONS  :  BUFF5; 

DATASET  :  BUFF4 ; 

ELEMENTS:  BUFF80; 

BUFFER  :  BUFF80; 

RLSE  :  BUFF4 ; 

I  :  INTEGER; 

PROCEDURE  DATBAS  (%STDESCR  FUNCTIONS  :  BUFFS;  STATUS  :  BUFF4 ;  DATASET 
VREFERENCE  :  BUFF4 ;  VLINKPATH  :  BUFF8 ;  SSAN  :  BUFF9 ; 
ELEMENTS  :  BUFF80;  BUFFER  :  BUFF80;  RLSE  : 

BUFF4) ;  FORTRAN; 


BEGIN 

FUNCTIONS  :=*  'READV'; 

DATASET  :=*  'SECL'; 

RLSE  :=»  'END.'; 

VLINKPATH  :=*  'STDTLKSE' ; 

ELEMENTS  :=  SECLCONST1+EXTRA; 

FOR  I  : *  1  TO  80  DO  BUFFER  [I]  :=  '  '; 

DATBAS  (FUNCTIONS,  STATUS,  DATASET,  VREFERENCE,  VLINKPATH,  SSAN, 
ELEMENTS,  BUFFER,  RLSE); 

CHECKSTATUS(OK) ; 

IF  OK  THEN  BEGIN 

FOR  I  :=■  I  TO  8  DO  SECL.SECT[I]  :=  BUFFER  [I]; 

FOR  I  :*  1  TO  9  DO  SECL.STDTtl]  :=  BUFFER  [1+8]; 

FOR  I  :=  1  TO  9  DO  SECL.FACT[lj  :=  BUFFER  [1+17]; 

END; 


{*  DATE:  18/07/85  *} 
{*  NAME:  FINDSECTION.PAS  *} 
{*  DESCRIPTION:  SEARCHES  THE  STUDENT  LINK  LIST  FOR  A  STUDENT  *} 
{*  THAT  BELONGS  TO  A  SPECIFIC  SECTION.  THIS  ALGORITHM  *} 
{*  ASSUMES  THE  LOCATION  PASSED  IS  EITHER  A  HEADER  RECORD  *} 
{*  OR  HAS  ALREADY  BEEN  SEARCHED.  *} 
{*  *} 
{*  FILES  READ:  *} 
{*  FILES  WRITTEN:  *} 
{*  GLOBAL  VARIABLES  USED:  *} 
{*  GLOBAL  VARIABLES  CHANGED:  *} 
{*  MODULES  CALLED t  *} 
{*  CALLING  MODULES:  *} 
{*  AUTHOR:  DAVID  A  GAITROS,  CAPT,  USAF  *} 
{*  *} 


PROCEDURE  FINDSECTION  (VAR  FIND:LINK_PTR;  SEARCHSECT: BUFF8) ; 

VAR  FOUND:  BOOLEAN; 

BEGIN 

FIND  :=*  FIND*. NEXT; 

FOUND  :=*  FALSE; 

WHILE  (FINDONIL)  AND  (NOT  FOUND)  DO 

IF  FIND*. SECT  -  SEARCHSECT  THEN  FOUND  :*  TRUE 
ELSE  FIND  :*  FIND*. NEXT 


END; 


{  ************************************************************************  J 


{*  DATE:  08/08/85  *} 
{*  NAME: ADVVCQR  *} 
{*  DESCRIPTION:  THIS  MODULE  ADDS  A  VARIABE  RECORD  TO  THE  VCQR  *} 
{*  VARIABLE  FILE  AFTER  THE  RECORD  POINTED  TO  BY  THE  *} 
{*  VREFERENCE  PARAMETER.  THE  INFORMATION  PASSED  TO  THIS  *} 
{*  MODULE  IS  IN  THE  RECORD  FORMAT  OF  TYPE  VCQR  REC.  *} 
{*  *} 
{*  FILES  READ:  NONE  AT  ALL  *} 
t*  FILES  WRITTEN:  AFITDB  *} 
{*  GLOBAL  VARIABLES  USED:  NONE  *} 
{*  GLOBAL  VARIABLES  CHANGED:  NONE  *} 
{*  MODULES  CALLED:  CHECKSTATUS  *} 
{*  CALLING  MODULES:  LAYER  4,  AND  LAYER  3  *} 
{*  AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF  *} 
{*  *} 


PROCEDURE  ADVVCQR( VCQR :VCQR_REC; VAR  VREFERENCE: BUFF4; CODE: BUFF9) ; 

VAR 

FUNCTIONS:  BUFF5; 

DATASET  :  BUFF4; 

VLINKPATH:  BUFF8 ; 

ELEMENTS  :  BUFF80 ; 

BUFFER  :  BUFF240 ; 

ENDIT  :  BUFF4 ; 

INDEX  :  INTEGER; 

OK  :  BOOLEAN; 

PROCEDURE  DATBAS  (%STDESCR  FUNCTIONS : BUFF5 ;  STATUS:BUFF4;  DATASET : BUFF4 ; 

VREFERENCE :BUFF4;  VLINKPATH: BUFF8 ;  CODE:  BUFF9 ; 

ELEMENTS:  BUFF80;  BUFFER:  BUFF240;  ENDIT:  BUFF4) ;  FORTRAN; 

BEGIN 

FUNCTIONS  'ADDVC'; 

ENDIT  :=  'END.'; 

VLINKPATH  :=  ' STDTLKCQ' ; 

DATASET  :=»  'VCQR'; 

ELEMENTS  :=  VCQRCONST1+EXTRA; 

FOR  INDEX  :«  1  TO  240  DO 
BUFFER  [INDEX]  :=  '  '; 

WITH  VCQR  DO 

BUFFER  :*CODE+NMBR+IDEN+SSSN+EXTRA+EXTRA+EXTRA+EXTRA+EXTRA+EXTRA; 
DATBAS  ( FUNCTIONS , STATUS , DATASET , VREFERENCE , VLINKPATH , CODE , ELEMENTS , 
BUFFER, ENDIT); 

CHECKSTATUS (OK); 

IF  OK  THEN  WRITELN(' RECORD  ADDED'); 

END;  {*  ADVVCQR  *} 
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{  ************************************************************************  } 


{*  DATE:  08/08/85  *} 
{*  NAME:  WRVVCQR  *} 
{*  DESCRIPTION:  THIS  MODULE  WRITES  AN  UPDATED  VARIABLE  RECORD  *} 
{*  FROM  THE  FILE  VCQR  TO  THE  DATABASE  TO  ITS  ORIGINAL  *} 
{*  POSITION  WITHIN  THE  STRING.  THE  INFORMATION  IS  PASSED  *} 
{*  TO  THE  MODULE  VIA  THE  RECORD  IN  THE  VCQR  REC  FORMAT.  *} 
{*  ~  *} 
{*  FILES  READ:  NONE  *} 
{*  FILES  WRITTEN:  AFITDB  *} 
{*  GLOBAL  VARIABLES  USED:  NONE  *} 
{*  GLOBAL  VARIABLES  CHANGED:  NONE  *} 
{*  MODULES  CALLED:  CHECKSTATUS  *} 
{*  CALLING  MODULES:  LAYER  4,  AND  LAYER  3  *} 
{*  AUTHOR:  DAVID  A  GAITROS,  CAPT,  USAF  *} 
{*  *} 


{ ************************************************************************ } 

PROCEDURE  WRVVCQR( VCQR : VCQR_REC ; VAR  VREFERENCE : BUFF4 ; CODE : BUFF9 ) ; 

VAR 

FUNCTIONS:  BUFF5 ; 

DATASET  :  BUFF4; 

ELEMENTS  :  BUFF80; 

VLINKPATH:  BUFF8 ; 

BUFFER  :  BUFF240; 

ENDIT  :  BUFF4; 

INDEX  :  INTEGER; 

OK  :  BOOLEAN; 

PROCEDURE  DATBAS  <%STDESCR  FUNCTIONS: BUFF5 ;  STATUS : BUFF4 ;  DATASET : BUFF4 ; 

VREFERENCE :BUFF4;  VLINKPATH : BUFF8 '  CODE:  BUFF9 ; 

ELEMENTS:  BUFF80;  BUFFER:  BUFF240;  ENDIT:  BUFF4) ;  FORTRAN; 


BEGIN 

FUNCTIONS  :=  'WRITV'; 

VLINKPATH  :=  ' STDTLKCQ' ; 

ENDIT  :«  'END.'; 

DATASET  :=■  'VCQR'; 

ELEMENTS  :«  VCQRCONST1+EXTRA; 

FOR  INDEX  :*  I  TO  240  DO 
BUFFER  [INDEX] 

WITH  VCQR  DO 

BUFFER  :-CODE+NMBR+IDEN+SSSN+EXTRA+EXTRA+EXTRA+EXTRA+EXTRA+EXTRA; 
DATBAS  ( FUNCTIONS , STATUS , DATASET , VREFERENCE , VLINKPATH , CODE , ELEMENTS , 
BUFFER, ENDIT); 

CHECKSTATUS (OK) 

END;  {*  WRVVCQR  *} 


{  ************************************************************************  J 


(* 

DATE:  08/08/85 

*} 

{* 

NAME:  RDVVCQR 

*} 

[* 

DESCRIPTION:  THIS  MODULE  READS  A  VARIBLE  FILE 

FROM  THE  DATABASE 

*} 

{* 

FROM  THE  FILE  VCQR.  IT  FORMATS  THE  INFORMATION  INTO 

*} 

{* 

A  RECORD  OF  TYPE  VCQR  REC  AND  RETURNS 

IT  TO  THE 

*} 

{* 

CALLING  PROCEDURE. 

*} 

{* 

*} 

{* 

FILES  READ:  AFITDB 

*} 

{* 

FILES  WRITTEN:  NONE 

*} 

{* 

GLOBAL  VARIABLES  USED:  NONE 

*} 

{* 

GLOBAL  VARIABLES  CHANGED:  NONE 

*} 

{* 

MODULES  CALLED:  CHECKSTATUS 

*} 

{* 

CALLING  MODULES:  LAYER  4,  AND  LAYER  3 

*} 

{* 

AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF 

*} 

{* 

*} 

PROCEDURE  RDVVCQR( VAR  VCQR: VCQR_REC;  VAR  VREFERENCE: BUFF4; 

CODE  : BUFF9) ; 


VAR 

FUNCTIONS:  BUFF5; 

DATASET  :  BUFF4; 

ELEMENTS  :  BUFF80; 

BUFFER  :  BUFF240; 

VLINKPATH:  BUFF8 ; 

END IT  :  BUFF4; 

INDEX  :  INTEGER; 

OK  :  BOOLEAN; 

I  :  INTEGER; 

PROCEDURE  DATBAS  (ZSTDESCR  FUNCTIONS : BUFF5 ;  STATUS : BUFF4 ;  DATASET: BUFF4; 

VREFERENCE: BUFF4;  VLINKPATH: BUFF8 ;  CODE:  BUFF9 ; 

ELEMENTS:  BUFF80;  BUFFER:  BUFF240 ;  ENDIT:  BUFF4) ;  FORTRAN 

BEGIN 

FUNCTIONS  :=  'READV'; 

ENDIT  :=  'END.'; 

VLINKPATH : =  ' STDTLKCQ' ; 

DATASET  :=  'VCQR'; 

ELEMENTS  :=■  VCQRCONSTI+EXTRA; 

FOR  INDEX  :=■  1  TO  240  DO 
BUFFER  [INDEX] 

DATBAS  ( FUNCTIONS , STATUS , DATASET , VREFERENCE , VLINKPATH , CODE , 
ELEMENTS , BUFFER, ENDIT) ; 

CHECKSTATUS(OK) ; 

WITH  VCQR  DO  BEGIN 
IF  OK  THEN  BEGIN 

FOR  I  :=*  1  TO  2  DO  CODE  [I]  :*  BUFFER  [I]; 

FOR  I  :=  1  TO  8  DO  NMBR  [ I]  :=  BUFFER  [1+2]; 

FOR  I  :*  1  TO  4  DO  IDEN  [ I]  :=  BUFFER  [1+10]; 

END 

END 

END;  {*  RDVVCQR  *} 
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fcv: 


V.v. 

H*.V. 

lejj. 


{  ************************************5ir******-*****************************  } 


{*  DATE:  08/08/85  *} 
{*  NAME:  RDDVCQR  *} 
{*  DESCRIPTION:  THIS  MODULE  READS  A  VARIABLE  FILE  RECORD  FROM  THE  *} 
{*  FILE  VCQR  DIRECTLY  FROM  THE  DATABASE  USING  THE  POINTER  *} 
{*  PARAMETER  PREFERENCE"  AS  THE  KEY.  THE  INFORMATION  IS  *} 
{*  FORMATTED  AND  STORED  IN  A  RECORD  OF  TYPE  VCQR_REC;  *} 
{*  *} 
{*  FILES  READ:  AFITDB  *} 
{*  FILES  WRITTEN:  NONE  *} 
{*  GLOBAL  VARIABLES  USED:  NONE  *} 
{*  GLOBAL  VARIABLES  CHANGED:  NONE  *} 
{*  MODULES  CALLED:  CHECKSTATUS  *} 
{*  CALLING  MODULES:  LAYER  4,  AND  LAYER  3  *} 
{*  AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF  *} 
{*  *} 


PROCEDURE  RDDVCQR( VAR  VCQR: VCQR  REC;  VAR  VREFERENCE : BUFF4 ; CODE : BUFF9 ) ; 


VAR 


FUNCTIONS 

BUFF5 ; 

DATASET 

BUFF4 ; 

ELEMENTS 

BUFF80 ; 

VLINKPATH 

BUFF8 ; 

BUFFER 

BUFF240; 

ENDIT 

BUFF4; 

INDEX, I 

INTEGER; 

OK 

BOOLEAN; 

PROCEDURE  DATBAS  (%STDESCR  FUNCTIONS : BUFF5 ;  STATUS : BUFF4 ;  DATASET : BUFF4 ; 

VREFERENCE :BUFF4;  VLINKPATH : BUFF8 ;  CODE:  BUFF9 ; 

ELEMENTS:  BUFF80;  BUFFER:  BUFF240;  ENDIT:  BUFF4) ;  FORTRAN 

BEGIN 

FUNCTIONS  :=»  'READD'; 

ENDIT  :=  'END.'; 

VLINKPATH  :=*  'STDTLKCQ' ; 

DATASET  :=*  'VCQR'; 

ELEMENTS  VCQRCONST1+EXTRA; 

FOR  INDEX  :*  I  TO  240  DO 
BUFFER  [INDEX]  :»  '  '; 

DArBAS  ( FUNCTIONS , STATUS , DATASET, VREFERENCE, VLINKPATH , CODE, 
ELEMENTS , BUFFER , ENDIT) ; 

CHECKSTATUS (OK) ; 

WITH  VCQR  DO  BEGIN 
IF  OK  THEN  BEGIN 

FOR  I  :*  1  TO  2  DO  CODE  [I]  :=  BUFFER  [ I] ; 

FOR  I  :*  1  TO  3  DO  NMBR  [I]  :=  BUFFER  [1+2]; 

FOR  I  :=■  1  TO  4  DO  IDEN  [I]  :=  BUFFER  [1+10]; 

END 


END 

END;  {*  RDDVCQR  *} 


H-51 


,  -V  -V  «*  /.  //  /. 


x-»  *-*  LtA  ■ 


*  -  •  •  *  *  '  *,*  ■  “  V*  ’  •  • 

,V  v,  vv  J*  •  wv  ,v  /  V 


. 


m  in >n ■  ii  ■ juuih  *ji 


>".  ■ ■  tf ' 


>  ir»v  ■ 


{  ************************************************************************ } 


{* 

DATE:  08/08/85 

*} 

{* 

NAME:  DLDVCQR 

*} 

{* 

DESCRIPTION:  THIS  MODULE  DELETES  A  RECORD  FROM  THE 

DATABASE 

*} 

{* 

FROM  THE  FILE  VCQR.  THIS  RECORD  MUST  HAVE 

BEEN  READ 

*} 

{* 

FIRST  WITH  INTENT  TO  UPDATE  AND  THE  RECORD 

POINTER 

*} 

{* 

PASSED  TO  THIS  MODULE  IN  THE  PARAMETER  "VREFERENCE". 

*} 

{* 

*} 

{* 

FILES  READ:  NONE 

*} 

{* 

FILES  WRITTEN:  AFITDB 

*} 

{* 

GLOBAL  VARIABLES  USED:  NONE 

*} 

{* 

GLOBAL  VARIABLES  CHANGED:  NONE 

*} 

{* 

MODULES  CALLED:  CHECKSTATUS 

*} 

{* 

CALLING  MODULES:  LAYER  4,  AND  LAYER  3 

*} 

{* 

AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF 

*} 

{* 

*} 

PROCEDURE  DLDVCQR(VAR  VCQR: «CQR_REC;  VAR  VREFERENCE: BUFF4; 

CODE  : BUFF9 ) ; 


VAR 


FUNCTIONS:  BUFF5 ; 
DATASET  :  BUFF4; 
ELEMENTS  :  BUFF80 ; 
BUFFER  :  BUFF240 ; 
VLINKPATH : BUFF8 ; 

END IT  :  BUFF4; 
INDEX  :  INTEGER; 
OX  :  BOOLEAN; 


PROCEDURE  DATBAS  (%STDESCR  FUNCTIONS : BUFF5 ;  STATUS : BUFF4 ;  DATASET : BUFF4 ; 

VREFERENCE: BUFF4;  VLINKPATH: BUFF8 ;  CODE:  BUFF9 ; 

ELEMENTS:  BUFF80;  BUFFER:  BUFF240 ;  ENDIT:  BUFF4) ;  FORTRAN; 


BEGIN 

FUNCTIONS  :=  'DELVD'; 

ENDIT  :=  'END.'; 

VLINKPATH  :=  ' STDTLKCQ' ; 

DATASET  :=  'VCQR'; 

ELEMENTS  :=  VCQRCONST1+EXTRA; 

FOR  INDEX  :=■  1  TO  240  DO 
BUFFER  [INDEX]  :=  '  '; 

DATBAS  ( FUNCT IONS , STATUS , DATASET , VREFERENCE , VLINKPATH , CODE , 
ELEMENTS , BUFFER , ENDIT) ; 

CHECKSTATUS(OK) ; 

END;  {*  DLDVCQR  *} 


H-52 


{*  DATE:  08/08/85  *} 
{*  NAME:  ADVFADV  *} 
{*  DESCRIPTION:  THIS  MODULE  ADDS  A  VARIABE  RECORD  TO  THE  FADV  *} 
{*  VARIABLE  FILE  AFTER  THE  RECORD  POINTED  TO  BY  THE  *} 
{*  VREFERENCE  PARAMETER.  THE  INFORMATION  PASSED  TO  THIS  *} 
{*  MODULE  IS  IN  THE  RECORD  FORMAT  OF  TYPE  FADV_REC .  *} 
{*  *} 
{*  FILES  READ:  NONE  *} 
{*  FILES  WRITTEN:  AFITDB  *} 
{*  GLOBAL  VARIABLES  USED:  NONE  *} 
{*  GLOBAL  VARIABLES  CHANGED:  NONE  *} 
{*  MODULES  CALLED:  CHECKSTATUS  *} 
{*  CALLING  MODULES:  LAYER  4,  AND  LAYER  3  *} 
{*  AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF  *} 
{*  *} 


PROCEDURE  ADVFADV ( FADV :FADV_REC; VAR  VREFERENCE :BUFF4; CODE :BUFF9) ; 

VAR 

FUNCTIONS:  BUFF5; 

DATASET  :  BUFF4; 

VLINKPATH:  BUFF8 ; 

ELEMENTS  :  BUFF80; 

BUFFER  :  BUFF200 ; 

ENDIT  :  BUFF4; 

INDEX  :  INTEGER; 

OK  :  BOOLEAN; 

PROCEDURE  DATBAS  (%STDESCR  FUNCTIONS : BUFF5 ;  STATUS :BUFF4;  DATASET : BUFF4 ; 

VREFERENCE :BUFF4;  VLINKPATH: BUFFS ;  CODE:  BUFF9 ; 

ELEMENTS:  BUFF80;  BUFFER:  BUFF200;  ENDIT:  BUFF4) ;  FORTRAN; 


BEGIN 

FUNCTIONS  :=  ' ADDVC' ; 

ENDIT  :=  'END.'; 

VLINKPATH  :=  'STDTLKCQ' ; 

DATASET  :=  'FADV'; 

ELEMENTS  :=  FADVCONST1+EXTRA; 

FOR  INDEX  :■  1  TO  200  DO 
BUFFER  [INDEX]  :*  '  '; 

WITH  FADV  DO 

BUFFER  : “SECT+STDT+F ACT+EXTRA+EXTRA+EXTRA+EXTRA+ EXTRA ; 

DATBAS  ( FUNCTIONS , STATUS , DATASET , VREFERENCE , VLINKPATH , CODE , ELEMENTS , 
BUFFER, ENDIT); 

CHECKSTATUS (OK) 

END;  [*  ADVFADV  *} 


DATE:  08/08/85  *} 

NAME:  RDVFADV  *} 

DESCRIPTION:  THIS  MODULE  READS  A  VARIABE  RECORD  FROM  THE  *} 

VARIABLE  FILE  AFTER  THE  RECORD  POINTED  TO  BY  THE  *} 

VREFERENCE  PARAMETER.  THE  INFORMATION  PASSED  FROM  THIS  *} 
MODULE  IS  IN  THE  RECORD  FORMAT  OF  TYPE  FADV  REC.  *} 

*} 

FILES  READ:  NONE  *} 

FILES  WRITTEN:  AFITDB  *} 

GLOBAL  VARIABLES  USED:  NONE  *} 

GLOBAL  VARIABLES  CHANGED:  NONE  *} 

MODULES  CALLED:  CHECKSTATUS  *} 

CALLING  MODULES:  LAYER  4,  AND  LAYER  3  *} 

AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF  *} 


PROCEDURE  RDVFADV( FADV :FADV_REC; VAR  VREFERENCE :BUFF4; CODE :BUFF9) ; 
VAR 

FUNCTIONS:  BUFF5 ; 

DATASET  :  BUFF4; 

VLINKPATH:  BUFF8 ; 

ELEMENTS  :  BUFF80; 

BUFFER  :  BUFF200; 

ENDIT  :  BUFF4; 

INDEX, I  :  INTEGER; 

OK  :  BOOLEAN; 


PROCEDURE  DATBAS  (%STDESCR  FUNCTIONS :BUFF5;  STATUS : BUFF4 ;  DATASET : BUFF4 ; 

VREFERENCE :BUFF4;  VLINKPATH: BUFF8 ;  CODE:  BUFF9 ; 

ELEMENTS:  BUFF80;  BUFFER:  BUFF200;  ENDIT:  BUFF4) ;  FORTRAN; 


BEGIN 


FUNCTIONS 
ENDIT  :=»  ' 
VLINKPATH 
DATASET  := 
ELEMENTS  i 
FOR  INDEX 


:=  'READV'; 

END.'; 

:=  ' STDTLKCQ' ; 
'FADV'; 

=*  FADVCONST1+ EXTRA; 
:=  I  TO  200  DO 


BUFFER  [INDEX] 

WITH  FADV  DO  BEGIN 

DATBAS  ( FUNCTIONS , STATUS , DATASET , VREFERENCE , VLINKPATH , CODE , ELEMENTS , 
BUFFER, ENDIT); 


CHECKSTATUS(OK) ; 
IF  OK  THEN  BEGIN 
FOR  I  1 
FOR  I  :*  1 
FOR  I  1 

END 

END  {*  WITH  *} 

{*  RDVFADV  *} 


1  TO  8  DO  SECT  [I] 
1  TO  9  DO  STDT  [I] 
1  TO  9  DO  FACT  [I] 


BUFFER  [ I] ; 
BUFFER  [1+8]; 
BUFFER  [1+17]; 
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{* 

DATE:  9/07/85 

*} 

{* 

NAME:  ADDNAME 

*} 

{* 

DESCRIPTION:  THIS  MODULE  ADDS  A  NAME  TO  A  LINK  LIST  PASSED  TO 

*} 

{* 

THE  MODULE  AS  A  PARAMETER. 

THIS  ROUTINE  WAS  DESIGNED 

*} 

{* 

TO  ADD  TO  A  FACULTY  LIST  OR 

STUDENT  LIST. 

*} 

{* 

*} 

{* 

FILES  READ:  NONE 

*} 

{* 

FILES  WRITTEN:  NONE 

*} 

{* 

GLOBAL  VARIABLES  USED:  NONE 

*} 

{* 

GLOBAL  VARIABLES  CHANGED:  NONE 

*} 

{* 

MODULES  CALLED:  NONE 

*} 

{* 

CALLING  MODULES: 

*} 

{* 

AUTHOR:  DAVID  GAITROS 

*} 

{* 

*) 

PROCEDURE  ADDNAME  (LINK:LINK_PTR;  VAR  HEAD:  LINK_PTR); 

VAR 

FOUND  :  BOOLEAN; 

PREV , CURR  :  LINK_PTR; 

BEGIN 

FOUND  :«  FALSE; 

IF  HEAD  =«  NIL  THEN  BEGIN 
NEW (CURR); 

CURR' . NAME  '  '; 

CURR' . CTRL  :«  '000000000'; 

CURR" .SECT 
CURR'. NEXT  :*  LINK; 

HEAD  CURR  {*  FIRST  RECORD  IN  LIST  *} 

END 

ELSE  BEGIN 

PREV  HEAD; 

CURR  :=  HEAD'. NEXT; 

WHILE  ((CURR  <>  NIL)  AND  (LINK'. NAME  >  CURR'. NAME))  DO  BEGIN 
PREV  :  =  CURR; 

CURR  :=  CURR'. NEXT 

END; 

LINK'. NEXT  :=  PREV'. NEXT; 

PREV'. NEXT  :=  LINK; 

END 


{< 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 

{* 


'} 

DATE:  09/07/85  *} 

NAME:  FINDNAME  *} 

DESCRIPTION:  THIS  ROUTINE  WILL  SEARCH  THE  SPECIFIED  LINK  LIST  *} 
FOR  A  NAME.  IT  WILL  ASSUME  THAT  THE  CURRENT  LOCATI5"ON  *} 
HAS  ALREADY  BEEN  SEARCHED  AND  THAT  THE  HEAD  RECORD  IS  A  *} 
IS  A  DUMMY  RECORD.  ALSO,  IN  CASE  OF  A  RECORD  NOT  FOUND,*} 
THE  RETURNED  NAME  FIELD  WILL  BE  BLANK.  NOTE  THAT  THE  *} 
NAME  RETURNED  WILL  BE  THE  FULL  NAME,  AND  THE  INPUT  NAME  *} 
WILL  BE  ONLY  THE  LAST  NAME  OR  ANY  PORTION  OF  IT.  *} 

NOTE:  WHENEVER  USING  THIS  ROUTINE,  BE  SURE  TO  PASS  IT  A  WORK  *} 

POINT  BECAUSE  ITS  VALUE  WILL  BE  CHANGED.  *} 

*} 
*} 
*} 
*} 
*} 
*} 
*} 

USAF  *} 

*} 


FILES  READ:  NONE 

FILES  WRITTEN:  NONE 
GLOBAL  VARIABLES  USED: 

GLOBAL  VARIABLES 
MODULES  CALLED: 

CALLING  MODULES: 

AUTHOR:  DAVID  A  GAITROS,  CAPT, 


NONE 
CHANGED: NONE 
NONE 


PROCEDURE  FINDNAME(VAR  NAME : BUFF28 ;  VAR  SSANOUT: BUFF9 ;  VAR  SEARCH  :LINK_PTR); 
VAR  FOUND, MATCH  :  BOOLEAN; 

INDEX  :  INTEGER; 

BEGIN 

SSANOUT 

FOUND  :»  FALSE; 

SEARCH  :=  SEARCH* .NEXT; 

WHILE  (NOT  FOUND)  AND  (SEARCH  <>  NIL)  DO  BEGIN 
INDEX  :-  1;  MATCH  :*  TRUE; 

WHILE  (MATCH)  AND  (NAME  [INDEX]  <>  '  ')  DO  BEGIN 

IF  NAME  [INDEX]  <>  SEARCH*. NAME  [INDEX]  THEN  MATCH  :=  FALSE; 

INDEX  :=*  INDEX  +  1 


END; 

IF  MATCH  THEN  BEGIN 
FOUND  :»  TRUE; 

SSANOUT  :=■  SEARCH* .CTRL; 
NAME  :=*  SEARCH". NAME 
END 
ELSE 

SEARCH  :*  SEARCH ".NEXT 

END 

END;  {*  FINDNAME  *} 


{*  DATE:  08/19/85 

{*  NAME:  FMS_INITIALIZE 

{*  DESCRIPTION:  THIS  MODULE  INITIALIZES  THE  CALLS  TO  FMS  AND 

{*  SETS  THE  SYSTEM  TO  READ  THE  FRAMES  IN  FROM  THE 

{*  FRAME  LIBRARY  SPECIFIED  IN  THE  FDV$OPEN  ROUTINE 

{*  CALL. 

{*  CALLING  MODULES:  MAIN 

{*  AUTHOR:  DAVID  A  GAITROS ,  CAPT,  USAF 

^XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX. 

PROCEDURE  FMS_INITIALIZE; 

BEGIN 

FDV$ATERM(TCA  :*  TCA,  SIZE  :=  12,  CHANNEL  :-  2); 

FDV$AWKSP  (WKSP  :=  WORKSPACE, SIZE  :-  2000); 
FDV$LOPEN('STDTMOD' ,1); 

END;  {*  FMS  INITIALIZE  *} 
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{*  DATE:  09/07/85  *} 
{*  NAME:  8UILDLINKLIST  *} 
{*  DESCRIPTION:  THIS  ROUTINE  BUILDS  THE  LINK  LIST  FOR  THE  *} 
{*  FACULTY  AND  STUDENT  FILE.  NAMES  ARE  STORED  IN  *} 
{*  ALPHABETIC  *} 
{*  ORDER.  *} 
{*  *} 
{*  FILES  READ:  AFITDB  *} 
{*  FILES  WRITTEN:  NONE  *} 
{*  GLOBAL  VARIABLES  USED:  NONE  *} 
{*  GLOBAL  VARIABLES  CHANGED: NONE  *} 
{*  MODULES  CALLED:  ADDFACT  *} 
{*  CALLING  MODULES:  *} 
{*  AUTHOR:  DAVID  A  GAITROS,  CAPT,  USAF  *} 
{*  *} 


c 


© 


PROCEDURE  BUILDLINKLIST(VAR  HEADER :LINK_PTR;  FILEIN: BUFF4) ; 

VAR  NAME:  BUFF28; 

SSAN:  BUFF9 ; 

NUMBER:  INTEGER; 

NUM  :  BUFF3; 

PTR.LINK:  LINK_PTR; 

SECTION:  BUFF8 ; 

SECL:  SECL_REC; 

VREF  :  BUFF4; 

ELEMENTS  :  BUFF40; 

INDEX  :  INTEGER; 

FUNCTIONS  :  BUFF5 ; 

DATSET  :  BUFF4; 

QUALIFIER:  BUFF4; 

ENDIT:  BUFF4; 

OK  :  BOOLEAN; 

BUFFER:  BUFF50; 

PROCEDURE  DATBAS ( %STDESCR  FUNCTIONS:  BUFF5 ;  STATUS:  BUFF4 ; 

DATSET  :  BUFF4;  QUALIFIER: BUFF4 ;  ELEMENTS:  BUFF40; 
BUFFER :BUFF50;  ENDIT:  BUFF4) ;  FORTRAN; 


BEGIN 


WRITELN(' BUILDING  LINK  LIST  OF  ' , FILEIN,'  FILE,  PLEASE  STAND  BY'); 


STATUS  :«  '  '; 

FUNCTIONS  :«  ' RDNXT' ; 

QUALIFIER  :*  ' BEGN' ; 

DATSET  :*  FILEIN; 

ENDIT  :-  'END  '; 

ELEMENTS  :-  FILEIN+'CTRL'+FILEIN+'NAME'+FILEIN+'RANKEND. '+EXTRA; 
BUFFER  :-  '  '; 

DATBAS ( FUNCTIONS , STATUS , DATSET , QUALIFIER , ELEMENTS , BUFFER , ENDIT) ; 
CHECKSTATUS(OK) ; 

WHILE  (OK)  AND  (QUALIFIER  <>  'END.')  DO  BEGIN 
NEW(LINK) ; 

FOR  INDEX  :»  I  TO  9  DO 

LltflT.  CTRL  [INDEX]  :-  BUFFER  [INDEX); 

FOR  INDEX  :-  1  TO  28  DO 
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LINK~ .NAME  [INDEX]  :*  BUFFER  [INDEX  +  9]; 

FOR  INDEX  :*  1  TO  3  DO 

LINK"'. RANK  [INDEX]  :=  BUFFER  [INDEX+37]; 

BUFFER  :=  ' 

IF  FILEIN  *  " STDT'  THEN  BEGIN 
VREF  'LKXX'; 

RDVSECL( SECL , VREF ,LINK“ . CTRL) ; 

IF  STATUS  -  '****'  THEN  LINK^.SECT  SECL. SECT; 

END; 

ADDNAME(LINK .HEADER) ; 

DATBAS ( FUNCTIONS , STATUS , DATSET , QUALIFIER, ELEMENTS , BUFFER, ENDIT) 
CHECKSTATUS(OK) ; 

END; 

END;  l*  BUILDLINKLIST  *} 


{  ***********************  *****  *********  ***********************************  J 


{* 

DATE:  10/01/1985 

*} 

{* 

NAME:  BUILDSECT 

*} 

{* 

DESCRIPTION:  THIS  ROUTINE  WILL  BUILD  A  SIMPLE  LIST  OF  ALL 

OF 

*} 

{* 

SECTIONS  CURRENTLY  IN  THE  DATABASE. 

THEY  WILL  BE 

*) 

{* 

STORED  IN  SEQUENTIAL  ORDER  IN  A  LIST 

OF  TYPE  LIST_ 

ARRAY 

.*} 

t* 

*} 

t* 

FILES  READ:  NONE 

*} 

[* 

FILES  WRITTEN :  NONE 

*} 

{* 

GLOBAL  VARIABLES  USED:  SECTION 

*} 

{* 

GLOBAL  VARIABLES  CHANGED:  SETION 

*} 

{* 

MODULES  CALLED: 

*} 

{* 

CALLING  MODULES:  MAIN 

*} 

{* 

AUTHOR:  DAVID  A  GAITROS,  CAPT,  USAF 

*) 

{* 

*} 

PROCEDURE  BUILDSECT; 

VAR 

FUNCTIONS:  BUFFS; 

DATASET  :  BUFF4 ; 

ELEMENTS:  BUFF80; 

SECT  :  SECT_REC; 

QUALIFIER:  BUFF4 ; 

BUFFER  :  BUFF40; 

END IT  :  BUFF4 ; 

INDEX, I  :  INTEGER; 

OK  :  BOOLEAN; 

PROCEDURE  DATBASUSTDESCR  FUNCTIONS:  BUFF5;  STATUS:  BUFF4 ;  DATASET:  BUFF4; 

QUALIFIER: BUFF4;  ELEMENTS:  BUFF80;  BUFFER: BUFF40;  ENDIT: BUFF4) ; 
FORTRAN; 

BEGIN 


FUNCTIONS  :»  ' RDNXT' ; 

DATASET  'SECT'; 

QUALIFIER  :-  ' BEGN' ; 

ELEMENTS  :-  SECTCONST1+SECTCONST2 ; 

FOR  INDEX  :-  I  TO  40  DO  BUFFER  [INDEX) 

ENDIT  :»  'END.'; 

WITH  SECT  DO  BEGIN 
INDEX  :«  0; 

DAT BAS ( FUNCTIONS , STATUS , DATASET , QUALIFIER, ELEMENTS , BUFFER, ENDIT) ; 
CHECKSTATUS(OK) ; 

WHILE  (OK)  AND  (QUALIFIER  <>  'END.')  DO  BEGIN 
IF  OK  THEN  BEGIN 

FOR  I  :-  1  TO  8  DO 
CTRL[ I]  :-  BUFFER  [I]; 

FOR  I  :-  1  TO  9  DO 
LSSN  [I)  :=  BUFFER  [1+24); 

INDEX  :-  INDEX  +  1; 

SECTION  [INDEX)  :*  SECT; 

END; 

DATBAS( FUNCTIONS, STATUS, DATASET, QUALIFIER, ELEMENTS , BUFFER, ENDIT) 


Appendix  J 

Standard  AFIT/ENG  Database  Procedures 

This  is  a  guide  to  the  beginning  or  casual  user  of  the 
AFIT/ENG  Database  System.  This  guide  contains  instructions  on 
the  procedures  needed  to  use  the  database  system,  logon  to  the 
system,  start  the  database  in  operation,  unlocking  the  database 
creating  tape  files,  printing  documents,  some  of  the  more 
requested  operations,  and  solutions  to  some  common  problems. 

Guide  Index 

1.  How  to  Logon  to  the  System. 

2.  How  to  Start  the  Database  in  Operation. 

3.  How  to  Unlock  the  Database  Files. 

4.  How  to  Create  a  Tape  for  RR. 

5.  How  to  Select  Items. 

6.  How  to  Check  to  See  if  TOTAL  is  Running. 

7.  What  to  Do  if  The  System  is  Not  Running. 

How  to  Exit  the  System. 
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l.HOW  TO  LOGON  TO  THE  SYSTEM. 


The  following  procedure  will  allow  you  access  to  the  system 
and  will  start  the  database  system  in  operation  for  you.  The 
items  in  BOLDFACE  are  the  ones  you  are  to  type  in.  When  the 
terminal  is  turned  on,  be  sure  the  keybourd  is  in  upper  case 
(caps  lock)  mode  for  best  results  with  the  database.  To  logon  the 
system,  perform  the  following  steps: 


$ USERNAME:  AFITDB 
$PASSWORD :  ENG  AFIT 


2.  HOW  TO  START  THE  DATABASE  IN  OPERATION 

When  logging  on  to  the  system,  sometimes  an  error  message 
such  as  STATUS  =  FAIL,  COMMUNICATION  ERROR  ( FATAL  ERROR)  will 
appear.  This  means  that  the  TOTAL  Data  Base  Management  System  is 
not  running.  This  procedure  will  allow  you  to  start  it  in 
operation  and  start  the  program  again. 

a.  Hit  the  keys  "CTRL"  and  "C"  at  the  same  time. 
This  will  stop  the  program  and  put  you  into  the 
operating  system.  A  $  should  appear  on  the 
screen . 

b.  Type  the  following  commands.  The  items  in 
BOLDFACE  are  the  instructions  you  must 
enter  . 

$SET  DEF  [AFITDB. TOTAL] 

$SUBMIT  TOTAL INI T 

Expect  some  messages  here. 

$RUN  TOTPRM 
>AFITDB 

>/ 

$SET  DEF  [-] 

$@ AFITDB 


3.  HOW  TO  UNLOCK  THE  DATABASE  SYSTEM 


Sometimes  when  a  program  you  or  someone  else  is  running 
aborts  or  stops  in  an  abnormal  manner,  this  locks  up  the  files  on 
the  database  system.  An  error  message  such  as  STATUS  ■  LOCK, 

DATA  SET  LOCK  (F)will  appear  when  this  occurs.  To  solve  this 
problem,  it  will  be  necessary  for  you  to  stop  the  program  you  are 
in  and  unlock  the  database.  To  do  this  follow  the  steps  below. 


a.  Stop  the  program  by  type  the  keys  "CTRL"  and 
"C"  at  the  same  time.  This  will  stop  the 
program  and  issue  a 

b.  Type  the  following  commands.  Remember,  you 
need  type  only  those  commands  in  BOLDFACE. 

$SET  DEF  [AFITDB.TOTAL] 

$RUN  ULK 

U  L  K  >  DBMOD  » AF I TDB 
ULK > FILES* ALL. 

ULK>/ 

$SET  DEF  {-] 

$@AFITDB 


NOTE:  A  common  mistake  is  forgetting  to  put  the 
period  (.)  at  the  end  of  FILES«ALL. 


4.  HOW  TO  CREATE  A  TAPE  FOR  RR. 


First,  all  sections  must  be  printed  by  using  the  print 
command  in  EDPLANS  (ED)  or  selecting  a  tape  generation  function. 
This  creates  the  file  SUMMARY.DAT  on  the  disk.  This  file  must  be 
transfered  from  disk  format  to  a  tape.  A  nine  blank  or  old  tape 
must  be  mounted  on  the  tape  drive  ( MSA0 : )  by  following  the 
instructions  underneath  the  cover.  Once  the  tape  has  been 
threaded,  close  the  lid  and  press  the  online  button,  and  then  the 
load  button  located  on  the  front  panel.  Perform  the  followinG 


a.  Hit  the  keys  "CTRL"  and  ”C"  at  the  same  time 
to  stop  any  program  running. 


b.  Enter  the  following  commands.  You  must  type 
only  those  commands  shown  here  in  BOLDFACE. 

$  INIT  MSA0: 

$MOUNT  MSA0: /FOREIGN 
$RUN  SYS $ SYSTEM : FLX 

FLX>/RS 

FLX>MS  0 : /ZE/DO 

FLX>NS0 : DU0 : [ AF I TDB ] SUMMARY . DAT 

FLX>MS0 : /DO/DI  {*  SHOW  LISTING  *} 

c.  Hit  the  keys  "CTRL"  and  "C"  at  the  same  time. 

d.  Unload  the  tape. 

5.  HOW  TO  SELECT  ITEMS 

This  data  base  system  is  called  a  menu  driven  program.  This 
means  that  you  perform  a  function  by  selecting  it  from  a  list  of 
functions  shown  on  the  screen.  These  will  appear  as  one  or  two 
alphapbetic  codes  or  numbers.  To  select  a  function,  just  type 
the  number  or  letter  (s)  shown  beside  the  function  and  hit  the 
"RETURN"  or  "ENTER"  key,  usually  just  to  the  right  of  the  left 
pinky  finger.  Anytime  you  are  confused  as  to  what  the  system  is 
expecting,  hit  the  PF2  key  located  on  the  keypad  to  the  right  of 
the  key  bouard. 

6.  ^OW  TO  CHECK  TO  SEE  IF  TOTAL  IS  RUNNING. 

To  check  to  see  if  TOTAL  is  running,  you  must  be  in  the 
operating  system.  Do  this  by  hitting  the  keys  "CTRL"  and  "C" 
at  the  same  time  and  then  type  the  following  command: 


$SHOW  QUEUE  SYS$BATCH 

The  response,  if  TOTAL  is  running,  will  appear  similar  to: 


JOBNAME 

USERNAME 

ENTRY 

STATUS 

TOTAL I NIT 

AFITDB 

status 

If  TOTAL  is  not  running  then  usually  nothing  will  appear. 

7.  WHAT  TO  DO  IF  THE  SYSTEM  IS  NOT  RUNNING 

Perform  function  number  2  of  this  document. 

8.  HOW  TO  EXIT  THE  SYSTEM 

Follow  the  directions  on  the  menus.  The  last  menu  you  see 
should  have  been  the  first  one  to  appear  on  the  screen  when  you 
logged  on.  When  you  type  "EX”,  this  will  stop  the  program  and 
log  you  off  of  the  system. 
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